RIPE Accountability Task Force Final Report

RIPE-723

Publication date:: 04 Jul 2019

State:: Published

Author

RIPE

File(s)

PDF (637.6 KB)

Overview

What is RIPE?
The difference between RIPE and the RIPE NCC
Why RIPE is reviewing its accountability now
How do we see accountability in RIPE?
Who is RIPE accountable to?
The benefits of accountability
Preventing capture

RIPE community values

Open
Transparent
Bottom-up decision-making process
Consensus in RIPE
Note on how we have approached consensus
What consensus is not
The role of chair
What kind of obligations are invalid

The role of documentation and standards

A lack of documentation is not necessarily a problem
Putting RIPE Documents into context

Components of RIPE accountability

Recommendations

Appendix 1: Relevant documents
Appendix 2: Relevant web pages on ripe.net
Appendix 3: Contributors

Overview

What is RIPE?

Réseaux IP Européens (RIPE) began in 1989 when a group of IP network operators in Europe started to exchange information, discuss common network practices, and carry out technical coordination work.

The Internet is a decentralised set of networks that interconnect on the basis of trust. In many ways, RIPE as a community mirrors this structure. From the early days, RIPE adopted an approach that was built around a handful of core values, often described as: open, transparent, bottom-up. Supporting these values was a reliance on consensus as the standard for making decisions.

From the beginning, it was made explicit that IP networks collaborating within RIPE remain under the authority of their respective organisations. Operators decide how they interconnect, and while RIPE develops policies that govern the distribution and registration of IP resources, it does not impose any rules in terms of how they should operate their networks.

As more network operators came to participate in RIPE, the amount of coordination work expanded rapidly. Over time, RIPE has grown from a handful of individuals in a room to a large and robust community that receives many hundreds of attendees per meeting, with thousands more subscribed to the various community mailing lists.

For more than 25 years, RIPE has been a forum open to anyone interested in Internet networking – primarily in Europe, the Middle East and parts of Central Asia, but also beyond. “The objective of RIPE is to ensure the administrative and technical coordination necessary for the operation of Internet networks.” [1]

Today, RIPE is a globally-recognised policy-making body. The community discusses a wide range of topics in a number of working groups[2], including (at the time of writing):

Address Policy: develops policies regarding the management and registration of Internet addresses and routing identifiers
Anti-Abuse: attempts to tackle online abuse via technical and non-technical approaches
Connect: discusses subjects related to IP interconnection
Cooperation: outreach with governments, regulators, NGOs, and others
Database: deals with all issues relating to the RIPE Database
DNS: discusses DNS-related issues in technology and operations
Internet of Things: facilitates the exchange of information, including developments in other standards bodies or governance structures, and may be used to develop positions regarding the Internet of things (IoT)
IPv6: follows the progress of specification and implementation of IPv6
MAT: data, tools and analysis relating to the Internet and its infrastructure
Open Source: fosters discussion among developers, ISPs and the rest of the RIPE community on open source projects
RIPE NCC Services: discusses the performance of RIPE NCC services, the introduction of new services, and evaluates the RIPE NCC Activity Plan
Routing: discusses IP routing technologies and routing registries

The difference between RIPE and the RIPE NCC

In 1990, RIPE decided to fund a “coordination center” with full-time staff to carry out work on behalf of the community.3 The RIPE Network Coordination Centre (RIPE NCC) was formally established in April 1992.

A point that often confuses newcomers is the relationship between RIPE and the RIPE NCC. It is important to note that these are two separate entities, though they are highly interlinked.

The RIPE NCC is a membership-based, not-for-profit association under Dutch law.[3] Some of the RIPE NCC's key activities include functioning as a Regional Internet Registry (RIR) responsible for distributing Internet number resources, providing secretariat support to the RIPE community, maintaining the RIPE Database, organising RIPE Meetings, and maintaining the RIPE Document Store and the various community and working group mailing lists.

RIPE (also referred to as the “RIPE community”) refers collectively to the group of like-minded individuals, whether members of the RIPE NCC or not, with an interest in the way the Internet is managed, structured or governed. RIPE is not a legal entity and has no formal membership. A person is considered to be a part of RIPE when they participate in the community.

The RIPE community provides input to the RIPE NCC's activities through RIPE Meetings and the various RIPE Working Groups.

Recommendation 1: The task force acknowledges the long-standing relationship between the RIPE community and the RIPE NCC. While there is a lot of goodwill involved, and an overlap between RIPE NCC members and RIPE community participants ensures alignment, there are no formalised commitments from the RIPE NCC to the community. While this has never been a problem to date, the task force nevertheless wishes to raise this as something for community to consider.

Why RIPE is reviewing its accountability now

In the autumn of 2016, stewardship of the Internet Assigned Numbers Authority (IANA) was transferred to the global Internet community. Oversight of IANA is now the responsibility of the Names, Numbers and Protocol Parameters communities that rely on its services.[4]

The Internet Corporation of Assigned Names and Numbers (ICANN) performs the role of “IANA functions operator”. As part of this transition, mechanisms were established to keep ICANN and its leadership accountable to the interests of the global Internet community.[5] Following the successful transition, attention shifted from ICANN as an organisation to the various Internet community structures and their accountability.

In 2016, the RIPE community established a task force to review its accountability. With community consent, the RIPE Accountability Task Force was established with the following scope: [6]

Review existing RIPE community structures, documentation and processes to ensure they are accountable and in alignment with RIPE values
Document existing RIPE community structures or processes where needed
Identify potential gaps where RIPE accountability could be improved or strengthened
Publish recommendations for the RIPE community
Identify areas where communications efforts or materials may be required

This document is the report of the RIPE Accountability Task Force following its review of the RIPE community.

How do we see accountability in RIPE?

The goal of RIPE participants is a functioning Internet, and coordination and interconnection is the only way to achieve this. However, the same network operators who cooperate within RIPE are often competitors in the marketplace. Accountability is a key part of how the community is able to reconcile these two factors.

Any decision made by RIPE has the potential to benefit or disadvantage individual network operators to varying degrees. Therefore, integral to RIPE’s success as a community is its ability to ensure that participants will accept that the decisions it makes are legitimate. If the community was unable to maintain the trust of its participants, it would quickly cease to be an effective policy-making forum and would be unable to facilitate coordination. For this reason, early RIPE participants recognised the need to continually evolve a series of accountability features as the community grew.

Preserving this trust means that participants can be sure their contributions to the decision-making process will be considered on their merits and that RIPE community decisions are valid ones – made on the basis of expert technical information, open and transparent structures, and following established processes.

With these accountability features, RIPE is able to justify its role and the decisions it makes, both to itself as a community and to external entities.

RIPE’s accountability features cannot guarantee that every decision made by the community will produce an ideal outcome that benefits all participants. However, because RIPE has these features in place, it can guarantee that it will produce accountable outcomes. It is also important to keep in mind that if the community decides a previous outcome is no longer appropriate, it can always be revisited and changed in the future.

Who is RIPE accountable to?

The Internet is much more than its technical dimensions alone. Many different parties have a stake in its operation, from governments and civil society groups, to business, academia and others. But while these stakeholder groups have a legitimate interest, RIPE cannot be accountable to all of them. RIPE can only be accountable to itself as a community of people interested in the technical coordination of Internet networks.

A counterbalance to this is that once someone from one of these stakeholder groups participates within RIPE, they are considered a community member. This means that RIPE will be accountable to them in terms of ensuring their input is given a fair hearing in any technical or community discussions. However, it is also important to note that their participation in RIPE is only as an individual – there are no constituencies in RIPE and they are not able to formally act as a representative of their stakeholder group.

Although RIPE’s scope has never been officially discussed and agreed upon, and may change as circumstances change, there is a general understanding that there are limits to the issues and problems it can address. RIPE is not an unlimited body – just because a problem exists does not mean it is RIPE’s problem to solve.

The RIPE community can only really work on issues where a consensus can be reached. In some cases, individuals may attempt to introduce issues into community discussions that are best addressed by other entities, whether government, law enforcement or regulators. These are generally issues that are not appropriate for a voluntary self-organising community to solve.

Finally, participating in RIPE doesn’t mean that someone will get what they want. Participation only guarantees an opportunity to contribute to discussions and play a role in the consensus process (which is dealt with later in this document). RIPE is not held accountable for serving the interests of individuals – in this sense it is only accountable to participants collectively.

The benefits of accountability

Accountability maintains the trust of participants in RIPE as a community. Because participants have this trust, they continue to view RIPE as an effective venue to set policy for the technical coordination of the Internet.

Participants can be sure that the community operates according to processes that are predictable, open and transparent. This encourages participation and attracts others to join, which strengthens the community. Wider and more effective participation is more likely to produce outcomes that receive broad support.

The fact that RIPE is an accountable community also enhances its legitimacy, both to participants and to outside observers. It demonstrates that the community is authoritative and can make important decisions concerning Internet infrastructure.

Preventing capture

Capture is usually understood in terms of a certain group dominating the decision-making processes within RIPE to produce outcomes that benefit itself at the expense of the wider community.

Having accountable structures in RIPE allows less room for malicious groups to make decisions in their own interest by taking over key positions in the community. RIPE participants have always been aware that there are risks associated with the capture of decision-making processes. This is an important concern, given that much of the legitimacy of RIPE rests on its ability to fairly address the concerns of many different individuals. Self-interested groups exercising undue influence over the community would compromise its integrity.

This is why the community consciously developed a separation of powers between individual working groups, the Working Group Chair Collective, RIPE Chair, RIPE Programme Committee, and other roles and structures. The community also uses an open and transparent approach that minimises the ability of individuals or groups to manipulate processes. Even if certain groups were successful in capturing critical positions in the community, RIPE structures would not allow them to make unilateral decisions.

For example, if a working group chair declared consensus on a policy that served their own business interest against a lack of consensus in the working group, we can expect that there would be a vocal response from the participants in that working group, who would have the option of challenging the consensus call via the appeals procedure in the RIPE Policy Development Process[7]. The Working Group Chair Collective (comprised of all RIPE Working Group Chairs) would then assess the consensus call, by looking at mailing list comments. The RIPE Chair is also able to make a final call in the event that the Working Group Chair Collective is unable to reach an agreement.

Another concern would be if a company or other group inserted supporters into the community to promote its agenda. The task force believes this would be harder to deal with through existing accountability structures, because it would affect the base of the bottom-up process. Nevertheless, it is the open, transparent nature of the community and the fact that it enjoys wide participation from a range of different individuals acting in good faith that minimises the risk of this type of capture. Importantly, the consensus process only examines technical arguments and is meant to be resistant to “vote stuffing.” An accountable RIPE community that attracts a wide base of active community members helps to minimise the risk of this type of capture “from the floor.”

The task force considered some version of capture where a future RIPE Chair might adopt some kind of “pay for play” approach or could be influenced by third parties covering various travel or accommodation expenses. It is worth noting here that the RIPE NCC covers all expenses associated with the performance of RIPE Chair duties. It is hard to imagine what these third parties might gain from this, as almost anything worthwhile would need to be done via the RIPE Policy Development Process, and the RIPE Chair’s influence here would be limited. Nevertheless, it is conceivable that this could happen.

Recommendation 2: The community might want to consider whether the RIPE Chair should be required to disclose details about expenses associated with performing RIPE Chair duties, and who covers these.

RIPE community values

When the first RIPE participants were establishing the community’s processes and structures, they consciously identified several process values that would guide the community going forward.

Open
Transparent
Bottom-up
Consensus-based decision-making

Today, the community expects these values to be built-in to all RIPE processes by default. They underscore the RIPE Policy Development Process, RIPE Working Groups, and plenary discussions at RIPE Meetings. These values relate to how RIPE works as a community and are deliberately limited in scope.

RIPE participants undoubtedly share a set of implicit values that are not related to how the community’s processes should work. For example, it might be argued that many participants believe in working towards an open Internet. Nevertheless, RIPE has intentionally avoided describing or formalising these kinds of values. This position was restated when the task force sought feedback from the RIPE community as part of this review. Aside from the fact that it would be difficult for the community to reach an agreement on which higher-level values it shared, having such values in place could come to limit the community in the future, and might cause some people to feel that they were not welcome to participate.

The RIPE community believes that decisions made according to open, transparent, bottom-up and consensus-based processes will produce the best outcomes.

Open

The coordination of networks can be of interest to a wide range of people. It is important that all voices (with something to say) are heard, and that RIPE policies and decisions are representative of the needs of those they apply to. Therefore, RIPE is open to anyone who wants to contribute to the development of policy or participate in discussions on Internet coordination. Accordingly, RIPE has no formal membership or participation requirements. Openness can also be understood in terms of accessibility – people should not be prevented from contributing by factors such as distance or cost.

Policy discussions take place on community mailing lists – therefore, the only real requirement for participation is access to an email account. In this way, RIPE allows all individuals with an interest to participate in its discussions, including those in other regions.

RIPE community and working group discussions also take place at RIPE Meetings and there are costs involved in attending (the cost of a meeting ticket, in addition to travel and accommodation). However, to counter this, there are remote participation options that allow people to contribute remotely at no cost, while working group and plenary sessions are filmed and publicly archived for later viewing.

Since 2016, the RIPE Fellowship[8] has covered the travel and accommodation costs of some worthy candidates to attend RIPE Meetings. Also, the RIPE Chair is able to waive the meeting fee for attendees that have a legitimate need. Finally, the requirement that contributions to policy discussions must be made on the mailing list if they are to be considered means that there is no procedural advantage to attending RIPE Meetings in person.

Transparent

For RIPE to maintain the trust of its participants and its legitimacy as a policy-making forum, community members need to be sure that important decisions are not being made behind closed doors and that relevant information is available. The RIPE community expects that all developments should be transparent to everyone.

Transparency is accomplished in the following ways:

Developments are announced through public mailing lists.
Mailing list discussions are archived and publicly available.
All discussions and developments that take place at RIPE Meetings are recorded, archived and publicly available. Transcripts and/or minutes of discussions are also archived and publicly available.
All RIPE policies and announcements are archived and publicly available.

Aside from the above list (which could be understood as “standard operating procedure”), the standard of transparency that is applied to a given situation may vary depending on what is appropriate for the particular goal and the demands of the community.

Bottom-up decision-making process

As the Internet is decentralised, a decision-making structure that was hierarchical and top-down would likely not be able to produce effective policy within reasonable timeframes. RIPE uses a bottom-up decision-making process that involves wide participation from anyone who wants to be involved.

Decisions in RIPE are not made by appointed leaders or other authorities within the community. For the most part, RIPE Working Group Chairs and others function as facilitators that encourage discussion and administer the community’s processes rather than as decision-makers themselves.

Consensus in RIPE

Finally, consensus is also understood as a value, especially since it is a core component of the bottom-up process value. However, as consensus plays such a central role in all aspects of RIPE decision-making, it was felt that this needed to be addressed separately.

The RIPE community uses consensus as its decision-making standard. Consensus is the best way to ensure community decisions take into account the varying and often conflicting views and priorities of those who participate in RIPE.

Note on how we have approached consensus

Over many years of policy development in RIPE, we have observed certain aspects of what consensus is and is not within the community. This report includes the observations of the task force.

The task force has included this section because it recognises the central role that consensus plays in the decision-making processes of the RIPE community – particularly the RIPE Policy Development Process. Any review of the community would therefore be incomplete if it did not touch on the role of consensus.

There is not an official definition of consensus that the RIPE community adheres to. However, there is a common understanding that the IETF’s definition of rough consensus matches more-or-less with the RIPE community’s understanding. In this document, we will ignore the term “rough consensus” and will only refer to consensus, which this is the term used in RIPE Documents.

It is important to be clear that there are no accepted RIPE Documents or community positions the task force could draw from to develop this description. The task force recognises that there are other aspects to consensus that it was unable to cover and (for example, this description primarily discusses what consensus is not rather than what it is).

Nothing in the description below should be taken to create new rules or requirements that the community must adhere to. In all cases, it is the relevant Chair, who has been selected by the community, that will determine whether consensus exists in a given situation.

What consensus is not

Below are some aspects that are useful when considering consensus:

Consensus is not unanimity
Consensus can exist when people still have objections, provided they are “invalid objections”. Invalid objections can be disregarded and do not need to be considered further. What determines whether an objection is valid or invalid is explored further in the relevant section below. The fact that one person (or a number of people) disagree with a proposal is not enough to prevent consensus being declared.

Consensus is not winning a vote
Consensus is not a singular event (a yes or no answer to a specific resolution). Rather, consensus is the process of reaching an agreement on how to solve a shared problem.

Consensus is not a majority opinion
Consensus requires that the community agrees (disregarding invalid objections). This means that the majority opinion does not necessarily prevail: if there is not general agreement for a proposal, it cannot be accepted, even if a majority support it.

Consensus is not a super-majority
Perhaps the most difficult and nuanced issue is that of a super-majority. Because consensus requires that “most” people in the community support a decision, but does not require complete unanimity, it is easy to mistake this for a super-majority, though perhaps one with an undefined threshold. This would be an error. What determines whether a small minority is able to block a declaration of consensus is not how many people agree, but the nature and quality of their objection – whether it is based on a valid argument. If there is a sizeable number of people objecting, this might indicate that the objection is valid, and only one-person dissenting might indicate that their objection is not valid. But numbers alone are not decisive.

The role of chair

The chair occupies a crucial role within almost all RIPE community structures. In particular, a working group chair is responsible for declaring whether a particular policy proposal has reached consensus or not. Typically, in any policy discussion, input can be sorted into a number of separate categories, such as:

Positive input for a proposal:

A supporting statement with an explanation
A statement of support without an explanation (often expressed on a mailing list as “+1”)
A statement of support with modification

Negative input against a proposal:

Objections with an explanation (both valid and invalid)
Objections with no explanation (which are invalid by default)

The chair determines which statements can be included in the discussion and which can be disregarded for various reasons that are explained below.

What kind of objections are invalid

There are several broad categories which invalid objections can be grouped under. Loosely, these might be considered “lack of good faith”, “out of scope”, and “asked and answered”.

Lack of good faith

The RIPE community is open to all who wish to participate. It is therefore possible that it will attract people who are deliberately disruptive or who simply seek to prevent the conduct of business. These kinds of objections should be disregarded when considering whether there is consensus in the community.

The RIPE community has already established that it has a valid purpose for existing, and it is able to legitimately develop policy or affect changes regarding Internet coordination. It may be that a person does not accept the legitimacy of the RIPE community or its authority as a venue for policy-making. This person may object to any policy or decision by RIPE, because they are opposed to RIPE in principle.

Such an objection should be disregarded as invalid because it essentially asks “Should RIPE exist?” and does not relate to the issue at hand. If the only disagreement within the community is from people who object to the existence of RIPE, then consensus can be declared to exist.

Technical decisions should be made on their merits. The RIPE community takes a dim view of people who would attempt to leverage its processes dishonestly. Accordingly, it is not valid for participants to willfully hold up decision-making on one issue so as to coercively silence dissent on another. If a dissenter is seeking to trade an offer to set aside their objection on one proposal in exchange for setting aside their (valid) concerns on another, this is an abuse of the process. Dissent from a person based on an attempt to game the system can properly be disregarded when assessing whether rough consensus exists.

The RIPE community is a collective enterprise that seeks to benefit the common good. Accordingly, positions that are based wholly on individual interest, disregarding the common good, can be themselves be excluded from an assessment of rough consensus. However, this ground for disregarding dissent must be employed carefully:

Dissent cannot be ignored simply because one side claims the moral high ground. It is wholly legitimate to disagree about where the common good lies. Accusations that one side is self-interested and harming the common good are not sufficient reason to disregard dissent.
It should also be remembered that the community is made up of individuals and entities, all of whom have legitimate personal interests. Each participant is a member of the community, and evidence of harm to members of the community is valid evidence in opposition to a proposal.
It is perfectly legitimate for a dissenter to oppose a proposal because they believe it is a poor decision, and to use evidence of how it would harm them personally in support of their case.

However, once it is clearly established that a proposal is beneficial to the community as a whole, and the only dissent is based entirely on the expectation that the proposal would cause harm or cost or reduced benefit to the dissenters themselves, then that dissent may be disregarded as invalid when considering whether consensus exists.

Out of scope

It is legitimate to disregard dissent where the reason for that dissent is not properly related to the matter at hand.

If the dissenter’s objection is simply unrelated to the issue, the fact that they express their opinion as opposition to the proposal can properly be disregarded when assessing whether consensus exists.
However, if two proposals, X and Y, are being considered separately, it is entirely proper to consider one as a dependency for the other if there is a legitimate interaction between them (i.e. that policy X is viable only if accompanied by policy Y). An opinion along these lines would be a legitimate objection and should not be disregarded.

Asked and answered

If someone raises a legitimate objection to a proposal, the response could be to answer their objection, or perhaps to modify the proposal.

The objection should properly be understood as the reasoning underpinning the objection and not the mere fact of opposition. The mere fact of opposition, without an underlying reason, would simply be obstruction.

Nor should the objection be understood as the dissenter’s proposed solution. If the dissenter raises a valid objection that a proposal produces a bad outcome – the solution is to address the relevant aspects of the proposal – not necessarily to implement the solution the dissenter would like.

A dissenter is entitled to stand on their opposition as long as a reasonable concern remains. Accordingly, if a dissenter maintains their opposition after their concern has been addressed, their opposition can be disregarded in an assessment of whether consensus exists. Their dissent may be disregarded even if the proposal has not been changed in the way that the dissenter wanted.

Other issues to consider when evaluating consensus

“Silence as Consensus” and “Rational Ignorance”

The amount of community participation can vary greatly between topics. Generally speaking, the more critical an issue or the wider its impact, the more people will provide input to the decision-making process.

Minor proposals will sometimes proceed with a relatively small level of community input. While this may be seen as a minority making decisions on behalf of the community, this is not necessarily an accurate view. The transparency and openness of the decision-making process allows the community to proceed on the assumption that the wider community will get involved if it feels it is in its interests to do so.

Where low participation is evident, it can generally be assumed that the wider community noticed the discussion was taking place, but rationally decided that:

Based on the expected impact, it was not worth the effort to learn about the issue and engage with it
They did not know as much as others involved in the discussion
They trusted other community members to produce an acceptable outcome

While broad and active participation is always preferred, the community’s silence can often be interpreted as “we have no strong objections.” It is therefore not a failure of the process if consensus on a certain proposal was reached with a relatively low level of community input.

It is up to the Chair to determine whether the input received on a proposal is sufficient and that the wider community has been adequately informed of ongoing discussions. If a policy proposal in a smaller working group would have a large impact, it is common for the Chair to notify other working groups of the discussion and invite them to participate.

This model relies on the good faith of the Chair and working group participants. One potential concern the task force discussed might be a group acting in bad faith that attempted to “forum shop” for a working group that would allow them to pass a self-serving proposal without the wider community being aware.

In practice, there are a number of informal mechanisms that minimise the risk of decisions taking the community by surprise. The Working Group Chairs meet as a collective at RIPE Meetings and communicate between meetings on a mailing list. RIPE community members participate in multiple working groups and engage in discussions with one another at RIPE Meetings and on mailing lists and at other venues.

Recommendation 3: The community could ensure that a formal process exists whereby all WGs are informed of any substantial policy change to ensure that nothing passes through without the wider community having an opportunity to comment. This would also ensure that if a chair was acting in bad faith, they would not be successful.

Self-interest vs collective interest

Individuals participate within RIPE because they have a shared interest in the successful operation of the Internet. At the same time, participants come to discussions with a range of different and often-conflicting interests (private, political, commercial, etc). RIPE has long understood that the best way to address this contradiction is by using consensus-based decision-making processes.

When the community takes a decision, it frequently balances the need and self-interest of some against the impact the decision would have on the wider community. Decisions are favoured that lead to the greatest good for the greatest number of people, or at least ensure that everyone is as “equally unhappy” as possible.

Input can be categorised as “self-serving” (and thus set aside) if it focuses too heavily on the self-interest of an individual or group at the expense of the wider community. However, it is likely that an issue that affects one network is shared by others, so this is only done with careful consideration.

The role of documentation and standards

Documentation supports the core RIPE values of openness and transparency. It ensures RIPE remains accountable to itself as a community and helps to demonstrate its accountability to external observers.

Documentation also helps newcomers to engage within RIPE, by describing current processes and recording previous decisions and how they were taken. Being able to see the history of RIPE helps to preserve its values over time. For people who have worked within RIPE for a long time, documentation clarifies the intent behind past decisions and ensures an alignment of purpose. It supports continuity in the community’s discussions.

One example is that until recently, there were no established processes for the selection of working group chairs. But this does not mean that chairs were not selected according to open, transparent, bottom-up processes and without the support of their working groups. More recently, the community realised that due to the evolution that has happened in the community (and Internet governance in general) there was a need for documenting this process. Documentation helps to demonstrate to newcomers and outsiders that chair selection is not a random process or a nepotism. When the community sees a need for documentation, it responds to this need.

However, while documentation can provide certainty and continuity, over-documentation can disempower newcomers by raising the barrier for participation. It can also weaken the flexibility of the community and undermine trust – by allowing room for pedantic interpretations and needless rules. Over-documentation could also empower those who might want to look for ways to game decision-making in RIPE.

It may happen that in an effort to have a documented process that would preserve the core values of the community, applying the process to the letter would actually contradict the intent behind the process. RIPE has consciously resisted becoming overly bureaucratic and avoids documentation for documentation’s sake. It remains flexible by avoiding rules wherever norms will do. This task force respects and endorses this tradition.

The task force recognises that RIPE has produced some very helpful and valuable documents, some of which are included in the appendix for reference. The RIPE NCC, in its secretariat role, makes sure that these documents are stored in a systematic way. Obsolete documents are clearly market and link to the replacement document where applicable. The date of their last evaluation is also recorded.

However, in conducting its review, the task force found that some RIPE Documents are marked as obsolete, but it is not clear why they were obsoleted and there is no replacement document linked.

Recommendation 4: The task force recommends that a brief explanation be included at the top of obsoleted RIPE Documents when there is no replacement document being referenced. It might also be worth considering another category such as “archived” for RIPE Documents that are no longer current, but not technically obsolete.

A lack of documentation is not necessarily a problem

RIPE has a set of both written and unwritten processes. When there are no written procedures, the community’s established norms and values apply.

Those with a prominent role in the RIPE community (chairs, etc) have been appointed by RIPE community participants through procedures. During their term, they are acting in accordance with these procedures. And according to unwritten rules or expectations. If they do not act in accordance with these rules and norms, they will be removed by the community.

For example, there is an expectation that all voices will be heard. That chairs will coordinate with other working groups as appropriate. Chairs will actively facilitate community discussions, set agendas, etc. If a chair doesn’t act in accordance with these expectations, the community will doubt their capacity and while there may not be specific procedures in every case, there is trust in the self-regulatory system and the appropriate outcomes will be achieved (either by requiring the chair to modify their approach, or by removing them from their role).

Putting RIPE Documents into context

The RIPE NCC maintains the RIPE Document Store[9] which currently contains slightly more than 700 RIPE Documents[10]. These are also available via FTP server.[11] Both obsolete and current RIPE Documents are published here, and where a new version of a document exists, both the updated and earlier versions are listed.

While RIPE Documents play an important role in how the community works, their purpose and function are not formally defined or explained anywhere. It is not immediately clear how the various types of RIPE Documents differ from one another, nor is it clear how RIPE Documents are different from other documents produced by community members or the RIPE NCC.

In terms of looking for an existing definition, RIPE Terms of Reference[12] mentions that “All documents produced by RIPE will be publicly available.” Aside from this, the only other early reference appears in the first activity plan for the (then proposed) RIPE Network Coordination Centre[13], which states: “The NCC will keep RIPE documents online and easily accessible to the RIPE community.”

Text on the RIPE Document Store states that RIPE Documents: “…include policies, reports or recommendations from RIPE Working Groups and Task Forces, as well as procedures or organisational documents relating to the RIPE NCC.” This is a reasonable description, as most RIPE Documents will fall into one of these categories. However, there are plenty of corner cases, especially with some of the earlier documents. Also, this description was likely developed by RIPE NCC staff at some point in the past as an introductory text and wasn’t mean to be taken as authoritative.

In most cases, RIPE Documents must pass through some form of gatekeeping process. This means that a RIPE Document can generally be read as having been approved by either the community or the RIPE NCC and thus has some degree of authority or weight behind it. However, the degree of weight that a RIPE Document should be given arguably varies depending on what kind of document it is. This is relatively straightforward when considering RIPE policies or RIPE NCC corporate governance documents, which are both published as RIPE Documents. This is less straightforward when looking at other kinds of RIPE Documents that don’t fall into either of these categories.

In the case of RIPE policies, there is a formal process that determines when they can be published as RIPE Documents. Namely: the policy text must pass through the various stages in the RIPE Policy Development Process (PDP)[14]. Only once this process has concluded will the new (or updated) policy be published as a RIPE Document. RIPE policies can be accessed as a separate category in the RIPE Document store[15]. Because RIPE policies describe (among other things) the conditions under which the RIPE NCC registers Internet number resources and the requirements for accessing and maintaining them, compliance with these is not optional.

Many of the RIPE NCC’s processes and procedures and other corporate governance documents are published as RIPE Documents. These are not subject to approval by the wider community, but rather by the RIPE NCC itself – which includes its Executive Board, its membership (via the GM), or RIPE NCC Management, depending on the document. Similar to RIPE policies, these should generally be read as authoritative statements, reporting, or requirements from the organisation. These RIPE Documents can also be accessed as a separate category (RIPE NCC Organisational Documents)[16]. More information on the process for the publication of these documents is available on the RIPE NCC’s website[17], but further review of this process is out of scope for this task force.

The remaining documents can be categorised in a number of different ways. They include best practices, recommendations, task force reports (including this one, if it is endorsed by the community), guidelines, and previously included RIPE Database manuals and resource request forms, though this information is no longer published as RIPE Documents. There is no formal process for how these documents are approved – though typically it will be the RIPE Chair or relevant working group chair who determines what is appropriate, in consultation with the community. In the case of task force reports or statements on behalf of the wider community, these will typically be approved by the RIPE plenary.

Generally speaking, there are no immediate accountability problems with this less-defined category – it probably wouldn’t serve the interests of the community if best practices needed to go through the RIPE PDP, for example. However, there is a risk that some documents may fall between the cracks. For example, the RIPE Document that describes the job description for WG chairs[18] was developed without input from the wider RIPE community. This is not in itself necessarily a problem, but it is also not immediately clear how it should be read – whether more as a set of guidelines, general expectations, or mandatory requirements as in the case of a RIPE policy.

A general confusion between the categories of RIPE Documents can also lead to situations where community members ask how they can create a policy proposal to modify a RIPE NCC organisational document (for which different procedures apply). This also contributes to the relatively common but incorrect belief that RIPE policies are created by the RIPE NCC. The community may wish to see if more can be done to distinguish between the different types of RIPE Documents and make it clear which are policies, which are RIPE NCC documents, and which are more general RIPE community documents and the degree to which these are mandatory requirements and how they can be amended.

The community might also wish to review some of the “metadata” that accompanies RIPE Documents, which can be found to the right of the web page when viewing it in the Document Store or at the top of the document when reading a PDF. In many cases “Author: RIPE NCC” helps to show that something is a RIPE NCC Document rather than a community document. In other cases, this metadata will show the community members who authored a document and/or the Working Group it came from. However, often these fields are missing or inconsistent. “Author” might refer to the original authors only up to a certain point, leaving out subsequent (or earlier) contributors. More importantly, other documents may leave out the working group field altogether. The community may wish to determine some consistent rules that can be applied to these fields going forward.

Recommendation 5: The community should consider whether more can be done to distinguish between the different types of RIPE Documents and whether consistency can be applied to the metadata for these documents moving forward.

Components of RIPE accountability

This section represents an attempt by the task force to identify the core structures of the RIPE community and the roles they perform.

Each of the core structures is dealt with in its own table. After a brief description of the structure and the task force’s observations, a list of the various roles included under this structure is provided in the left-hand column (“Role”). Next to each role, under “Process”, there is a reference to whether this is documented anywhere (whether in a RIPE Document or on a web page on the RIPE NCC’s website). Next is a reference to whether the outcome of the performance of this role is reported (“Decisions”), along with an example where this might be helpful. Finally, there is an evaluation from the task force on whether the role is adequately described and reported – which is either “Meets expectations” or “Needs review”.

Meets expectations: This means that the current documentation/reporting is adequate. The task force took the stance that not every role or activity must be documented – this is applied differently to meet the accountability standards of the RIPE community.

Needs review: The task force believes that the community should review the situation with the current documentation to verify that it meets accountability expectations.

The following structures are analysed further below:

RIPE Chair
Working Group Chairs
Working Groups
Working Group Chair Collective
Task Forces
RIPE Programme Committee
Plenary
RIPE Meeting attendees

1.0 RIPE Chair The RIPE Chair is responsible for ensuring the functioning of RIPE and performs a range of different roles. A new RIPE Document was published after the first draft of this report which documents the responsibilities of the RIPE Chair. The community continues to discuss a procedure for selecting future RIPE Chairs. The task force believes that the community needs to make progress on finalising the RIPE Chair selection procedure (recommendation 6). Part of the RIPE Chair’s role (as noted in 1.5) is representing the RIPE community in other forums. While there have never been questions about the integrity of RIPE Chairs or their performance of this role, the task force wonders if there should be periodic reporting to the community on this activity (recommendation 7). Note: an updated RIPE Chair role description (ripe-714) was published after the task force had prepared its draft report. We have therefore not evaluated many of these roles as they are described in the document or whether any reporting meets expectations/need review.
Role	Process	Decisions	Evaluation
1.1 Final word in PDP disputes	ripe-710, “Policy Development Process in RIPE”	A PDP dispute has never been escalated to the RIPE Chair before. If such a decision were taken, it would be announced on the relevant mailing list. The RIPE NCC has a draft web page it would publish that records the decision.	Meets expectations
1.2 Final word on location of RIPE Meetings	RIPE Meeting Location Selection Process	-Upcoming RIPE Meetings-Various MLs (example)	Meets expectations
1.3 Chairs RIPE WG Chair collective	ripe-714, "The RIPE Chair"	-WG Chair Collective Meeting Summaries	Needs review
1.4 Chairs RIPE Meetings	ripe-714, "The RIPE Chair"	Not applicable	Needs review
1.5 Informally represents the RIPE community in other forums	ripe-714, "The RIPE Chair"	No reporting	Needs review
1.6 Sets agenda for RIPE Meetings Note: in practice, the RIPE Chair is only directly responsible for allocating meeting slots to working groups and for the agenda of the first Friday morning session. Responsibility for the remaining meeting agenda is delegated to the relevant WG Chairs and the RIPE Programme Committee.	ripe-714, "The RIPE Chair"	-RIPE Meeting Plan[4]	Needs review
1.7 Makes final decision on waiver of RIPE Meeting fees	About RIPE Meetings	No reporting	Meets expectations
1.8 Ensures that RIPE establishes consensus about how it operates, particularly concerning formal procedures	ripe-714, "The RIPE Chair"	There is no established procedure around reporting plenary decisions back to the community. This is done on a case-by-case basis.	Not reviewed
1.9 Ensures that useful WGs and task forces are properly created, chartered and disbanded	ripe-714, "The RIPE Chair"	Not reviewed	Not reviewed
1.10 Ensures that WG Chairs are properly selected	ripe-714, "The RIPE Chair"	Not reviewed	Not reviewed
1.11 Chairs and supports the WG Chair collective as necessary	ripe-714, "The RIPE Chair"	Not reviewed	Not reviewed
1.12 Monitors the work of RIPE and intervenes when necessary	ripe-714, "The RIPE Chair"	Not reviewed	Not reviewed
1.13 Ensures that the results of RIPE work are communicated to other parties, such as the RIPE NCC, other organisations and government bodies	ripe-714, "The RIPE Chair"	Not reviewed	Not reviewed
1.14 Reports their actions to the community as appropriate	ripe-714, "The RIPE Chair"	Not reviewed	Not reviewed
1.15 May delegate their duties to an appropriate person or entity such as the RIPE NCC or a WG Chair, the programme committee	ripe-714, "The RIPE Chair"	Not reviewed	Not reviewed

2.0 Working Group Chairs Working Group Chairs facilitate the work of working groups and declare consensus on policy proposals. Many functions of this role are documented. Recommendation 8: While the current approach of having each working group maintain its own chair replacement procedure is consistent with a bottom-up approach, the task force believes inconsistencies in chair selection should be aligned across the community to provide more clarity (and notes this is already being discussed by the WG Chair Collective). The task force notes that there is no formal process to educate new chairs on their role within the community. This does not need to be anything onerous – but perhaps the RIPE NCC could share a set of relevant documents, responsibilities and timelines with newly-selected chairs (recommendation 9). Similarly, perhaps a “crash course” could be developed to educate new chairs that covers things like how to effectively chair a session or declare consensus (recommendation 10).
Role	Process	Decisions	Evaluation
2.1 Determine whether a proposal can move to the next step in the PDP and declare consensus	ripe-710, “Policy Development Process in RIPE”	-ML announcements (example)	Meets expectations
2.2 Assign action items to the RIPE NCC and others based on WG input	ripe-692, “RIPE Working Group Chair Job Description and Procedures”	-ML or RIPE Meeting Minutes (example)	Meets expectations
2.3 Announce final best practice documents (or other output) created by WGs	No	-ML (example)	Meets expectations
2.4 Moderate mailing list/RIPE Meeting discussions	ripe-692, “RIPE Working Group Chair Job Description and Procedures”	-ML (example) -RIPE Meeting Minutes(example)	Meets expectations
2.5 Propose agenda for RIPE Meetings and solicit relevant presentations	ripe-692, “RIPE Working Group Chair Job Description and Procedures”	-ML (example)	Meets expectations
2.6 Declare consensus on any topic raised in the WG	No	Reported in WG minutes and on mailing lists	Meets expectations
2.7 Approve minutes from RIPE Meetings	No	Takes place on mailing list or in working group session at RIPE Meetings	Meets expectations
2.8 Develop, maintain and implement a WG Chair replacement procedure	ripe-692, “RIPE Working Group Chair Job Description and Procedures”	Discussed on mailing lists and at RIPE Meetings (example)	Needs review

3.0 Working Groups Working groups are one of the main bodies that the RIPE community is structured around. Working groups discuss and decide on policies that the RIPE NCC will implement. Currently only the Policy Development Process and the different working group chair selection procedures are documented. Recommendation 11: While the scope of each working group is documented, there is not much of a general description or a guide around how working groups function or how people are expected to participate within them. While the task force doesn't see any accountability issues associated with this, it feels that it would help newcomers and some existing community members to provide some kind of a description. As mentioned above under 2.0 Working Group Chairs, the task force believes that the RIPE community should review whether the current practice of having each working group maintain its own chair replacement procedure is the best approach.
Role	Process	Decisions	Evaluation
3.1 Select WG Chairs	Working Group Chair Selection	-ML or RIPE Meeting minutes (example 1 2)	Needs review
3.2 Discuss policy proposals	ripe-710, “Policy Development Process in RIPE”	-ML or RIPE Meeting Minutes (example)	Meets expectations
3.3 Discuss best practices and other topics	No	-ML or RIPE Meeting minutes (example)	Meets expectations

4.0 Working Group Chair Collective The Working Group Chair Collective meets regularly at RIPE Meetings and as necessary to discuss issues relating to meetings and working groups. Very little of this function is currently documented and more information might be helpful (recommendation 12). Since RIPE 67, the collective has published summaries of its meetings during RIPE Meetings. This is helpful for transparency and is a positive development.
Role	Process	Decisions	Evaluation
4.1 Escalation in disputed WG Chair PDP decisions	ripe-710, “Policy Development Process in RIPE”	A PDP dispute has never been escalated to the RIPE Chair before. If such a decision were taken, it would be announced on the relevant mailing list. The RIPE NCC has a draft web page it would publish	Meets expectations
4.2 Discusses RIPE Meeting plan (RIPE Chair makes the final decision)	No	-WG Chair Collective Meeting Summaries	Meets expectations

5.0 Task Forces

Task forces produce reports with recommendations that are discussed by the RIPE community. Task forces were originally described in ripe-004, however this document is obsoleted, and no new RIPE Document has replaced it. The text from ripe-004 was reproduced on ripe.net and no longer seems fit for purpose. A definition of task forces is provided in ripe-464, “Report of the Enhanced Cooperation Task Force” which may be sufficient (recommendation 12).

Role

Process

Decisions

Evaluation

5.1 Produce a report with recommendations that will be discussed by the RIPE community and implemented when consensus is reached

-RIPE Task Forces-ripe-004, "Task Force Description"
(Obsoleted)
-ripe-464, “Report of the Enhanced Cooperation Task Force”

-Task force report (example)

Needs review

6.0 Programme Committee The RIPE Programme Committee (PC) is responsible for the RIPE Meeting plenary content. The RIPE PC Charter explains how members are selected and gives an overview of their role.
Role	Process	Decisions	Evaluation
6.1 Decide on Monday-Tuesday RIPE Meeting Plenary programme	ripe-600, “Charter of the RIPE Programme Committee”	-RIPE Meeting Plan[4]	Meets expectations
6.2 Chair Plenary sessions	No	N/A	Meets expectations

7.0 Plenary The plenary refers to the attendees that (either physically or remotely) participate in plenary sessions at RIPE Meetings. Few of the plenary’s powers are currently documented. Recommendation 14: The task force feels that more could be done to outline what the plenary can do and how it makes decisions. Plenary decisions are not formally documented anywhere, and minutes are not taken of the closing plenary where the community can make significant decisions.
Role	Process	Decisions	Evaluation
7.1 Approve new WGs	No	No reporting	Needs review
7.2 Accept a TF’s recommendations and open/close TF	No	No reporting	Needs review
7.3 Escalation for arbitration regarding resource requests by the RIPE NCC and other conflicts between RIPE NCC members and the RIPE NCC regarding Standard Service Agreements	ripe-635, “Allocating/Assigning Resources to the RIPE NCC” ripe-670, “RIPE NCC Conflict Arbitration Procedure”	Summary of Arbitration Rulings	Meets expectations
7.4 Issue recommendations/BCPs	No	No reporting	Needs review
7.5 Ratifies/approves community decisions – e.g. might approve a communication to the ITU	No	No reporting	Needs review
7.6 Makes consensus decisions on small issues brought up by the Chair	No	No reporting	Needs review

8.0 RIPE Meeting Attendees The attendees that participate in RIPE meetings (including plenary sessions and WG sessions).
Role	Process	Decisions	Evaluation
8.1 Elect PC members	ripe-600	-RIPE Programme Committee-Daily Meeting Reports (example)[1]	Meets expectations
8.2 Elect NRO NC members from the RIPE region	NRO NC / ASO AC Election Procedure	-NRO NC Nominations 2016-ML announcements (example)	Meets expectations

Recommendations

Based on its review, the task force has a number of recommendations it would like the RIPE community to consider.

Consider whether any formalised commitments are needed from the RIPE NCC (that it will implement policy, follow relevant community directions, etc).
Consider whether the RIPE Chair should be asked to disclose financial details associated with performing RIPE Chair duties and who covers these.
Consider reviewing whether current informal safeguards are enough to prevent bad actors from passing a policy proposal without the wider community having an opportunity to comment (not a great risk in the task force’s view).
Consider including an explanation at the top of obsoleted RIPE Documents when there is no replacement document that it refers to. Possibly create a new “Archived” status for documents that are no longer current, but not exactly obsolete.
The community should consider whether more can be done to distinguish between the different types of RIPE Documents and whether consistency can be applied to the metadata for these documents moving forward.
The task force believes that the community needs to make progress on finalising the RIPE Chair replacement procedure.
Consider whether the RIPE Chair should report back to the community after representing RIPE in other forums.
Consider aligning the process for selecting working group chairs across the community.
Consider having more of a standardised process for informing new WG Chairs about relevant RIPE Documents and their responsibilities.
Consider developing a “crash course” for new chairs that covers things like how to effectively chair a session or determine consensus.
Consider developing general information for newcomers to explain how to participate in working groups, task forces and BoFs and how the community functions more generally (the RIPE NCC could be tasked to produce this content)
Consider providing an overview of what the Working Group Chair Collective does and what it is responsible for.
The RIPE Document that defines task forces is obsolete, and the working description on ripe.net no longer seems fit for purpose. Consider updating this with the description provided in ripe-464, which has been accepted by the RIPE community.
Develop documentation around the plenary and what its powers are. Also consider doing more to record closing plenary decisions which are not minuted currently.
Consider putting in place some kind of semi-regular review of the RIPE community’s accountability

Appendix 1: Relevant documents

RIPE Documents	Document Number and Link
RIPE Terms of Reference	ripe-001
Letter of Introduction (obsoleted)	ripe-003
RIPE Network Coordination Centre (obsoleted)	ripe-019
RIPE Recommendation on IP Router Management (obsoleted)	ripe-037
Relationship Between A & R Networks and Commercial Networks (obsoleted)	ripe-045
General Information About RIPE and the RIPE NCC (obsoleted)	ripe-057
RIPE Task Forces (obsoleted)	ripe-066
Report of the RIPE Enhanced Cooperation Task Force	ripe-464
Principles for Number Resource Registration Policies	ripe-495
Final Report of the RIPE Meeting Task Force	ripe-550
Charter of the RIPE Programme Committee	ripe-600
Working Group Chair Job Description and Procedures	ripe-692
Policy Development Process in RIPE	ripe-710
Documents Relating to RIPE Chair Selection
The RIPE Chair (Function Description)	DRAFT: RIPE Chair Function Description
DRAFT: RIPE Chair Selection Procedure	DRAFT: RIPE Chair Selection Procedure
Updated Draft RIPE Chair Selection Process (subject to change)	RIPE Chair Selection Process

Appendix 2: Relevant web pages on ripe.net

Topic	Page Title and Link
Details about the RIPE Accountability Task Force	RIPE Accountability Task Force
Some early history of RIPE	History of RIPE
Landing page for section that explains RIPE Policy Development, with links to current and archived policy proposals	RIPE Policy Development
Information on RIPE Meetings	About RIPE Meetings
Selection of RIPE Meeting locations	RIPE Meeting Location Selection Process
Procedures for selection of WG Chairs	Working Group Chair Selection
Selection of NRO NC members	NRO NC/ASO AC Election Procedure
RIPE Meeting code of conduct	RIPE Meeting Code of Conduct
List of active working groups	Active Working Groups
List of inactive working groups	Inactive Working Groups
Landing page for summaries and agendas of WG Chair Collective meetings	Working Group Chair Collective
List of active/inactive task forces	RIPE Task Forces
Description of BoFs and list of previous BoFs	BoF (Birds of Feather) Gatherings

Appendix 3: Contributors

The following people contributed to the writing of this report:
William Sylvester (Chair), Athina Fragkouli, Antony Gollan, Malcolm Hutty, Alexander Isavnin, Peter Koch, Paul Rendek, Wim Rullens, Carsten Schiefner, Marco Schmidt.