Evolving MANRS by Formalizing a MANRS Development Process

[Tony Tauber is the Chair of the MANRS Steering Committee.]

MANRS began as a small group of network operators discussing a minimum set of best practices that could be widely implemented to improve routing security for the entire Internet. In the decade since, it has grown into the powerhouse community we know today, adding programs for IXPs, CDN & Cloud Providers, and Equipment Vendors with its actions and recommendations cited in technical and policy pieces around the world.    

Each program was developed by a task force or working group, feedback from the broader community was solicited, and all MANRS participants had a chance to voice their opinions during “last calls” before approving the Actions and launching the program. Similarly, the Community Charter and Implementation Guides for Network Operators and IXPs each went through rigorous review cycles before being published. However, this process itself hasn’t been fully documented.

Why do we need a formal process? 

As MANRS continues to grow and evolve, we realize that it is time to formalize our processes to ensure that the requirements are clearly articulated, that those requirements are always met, and that the resulting documents can be referenced in a systematic and organized way. This heightened level of document control will help ensure transparency, consistency, and traceability throughout a document’s lifetime, from creation to revision to deletion. 

It’s time for a MANRS Development Process (MDP), which is a consensus-based, transparent way to add or amend required and recommended Actions, agree to the updates as a community, update the documents accordingly, and then track different versions of the documents over the years. Ensuring that this process is open, transparent, and consensus-based improves the quality and credibility of the Actions to wider audiences.

Formalizing this process will create a stable and confident reference to MANRS Actions and other documents we create. MANRS is already being cited in various technical recommendations and policy documents, often as a simple link to a page on our website or to the initiative as a whole. To promote MANRS as a set of requirements for procurement practices, or to be able to point to it from common information security frameworks, we need a stable reference to a specification with version control.

What are the requirements?

Most standard development organizations apply common requirements to their development process including openness, consensus, and transparency. Their specifications have documented maintenance procedures, they are publicly available, and meet requirements for technical competence. These are all things MANRS is already striving for. 

These requirements can be found in the WTO Principles for the Development of International Standards, Guides and Recommendations, in the EU requirements for identification of tech specifications developed by consortia and fora (Annex II of Regulation 1025/2012 on European Standardisation), and in the specification of the the IETF Internet Standards Process. 

In short, these requirements generally outline the following qualitative criteria:

1. Openness: The development of a standard is based on open decision making accessible to all stakeholders affected by those technical specifications.
2. Consensus: The decision-making process is collaborative and consensus based and does not favor any particular stakeholder. Consensus means a general agreement, characterized by the absence of sustained opposition to substantial issues by any important part of the concerned interests and by a process that involves seeking to take into account the views of all parties concerned and to reconcile any conflicting arguments. Consensus does not imply unanimity.
3. Transparency: All information concerning technical discussions and decision making is archived and identified. Information on new standardization activities is widely announced through suitable and accessible means. Participation of all relevant categories of interested parties is sought with a view to achieving balance. Consideration and response is given to comments by interested parties.

There are several requirements related to the specification itself, such as:

1. Maintenance: Ongoing support and maintenance of published specifications is guaranteed over a long period. This includes a well-defined publication series, document versioning, and identification.
2. Availability: Specifications are publicly available.
3. Quality: The quality and level of detail is sufficient to permit the development of a variety of competing implementations of interoperable products and services. In our case – the implementation of MANRS Actions.

We are proposing a fairly simple process that meets these requirements. The process can be applied, with slight modifications as needed, to a variety of MANRS documents – from normative documents like the Community Charter and MANRS Actions, to informational and educational documents like the MANRS implementation guides.

What is the process?

It’s worth noting that for this MANRS Development Process, the MANRS Community is broader than only the MANRS Participant organizations; it also includes individuals supporting MANRS, its mission, and its objectives, like technologists, researchers, members of civil society, and policymakers.

Participation in the MANRS Development Process is in a personal capacity.

The MANRS Development Process will generally follow the following phases:

1. Proposal. Any MANRS Community member can submit a proposal to the Secretariat. The Secretariat will check to ensure it’s valid (not incomplete, spam, etc.) and then forward it to the Steering Committee for consideration. 
2. Discussion. The Steering Committee may (a) reject a proposal based on its relevance and quality; (b) advance a proposal straight to the Public Comment phase; (c) task the proposal writer with further developing the proposal; or (d) charter a working group (WG) to further develop the proposal. Anyone from the MANRS Community can join a WG.
3. Public Comment. Once the Steering Committee has reviewed the final draft proposal, the Secretariat will send the proposal to the manrs-community mailing list for comment. Because many proposals will likely have a direct impact on the MANRS Participants, it is important to receive an explicit approval from them. The “MANRS Last Call” serves this purpose. It takes place on the manrs-participants mailing list that includes primary and secondary contacts of all participant organizations.
4. Ratification and Implementation. If consensus is reached after the Last Call, the Steering Committee will ratify the document and publish it.

Please note that this is a simplified version of the full process, which will include more detailed steps and information. 

What’s next?

We will bootstrap, discuss, and debug this process by using it to approve the process itself.

In this case, over the past few months, the Steering Committee tasked the Secretariat with preparing a proposal for a MANRS Development Process (Step 1). Now, the SC has decided to advance this proposal straight to the Public Comment phase (Step 2). Please stay tuned for Step 3, when we share the detailed MANRS Development Process with the MANRS Community.

Does this process sound about right? Are any key steps missing? Getting these things right is important and we need a clear consensus before moving on to Step 4, the final ratification and implementation. 

If you are interested in this discussion, please make sure that you are subscribed to the manrs-community mailing list by sending a request to [email protected]. And if you are a MANRS participant, check that your primary and secondary contacts are up to date in the MANRS Observatory by logging in and checking Profile in the upper right corner of the screen.

Please contact us here to share your feedback!