View All Proposals

Document ID:              MANRS-001.01
Specification Type:       Normative
Publication Date:         4 April 2025

Abstract

This document describes the MANRS Development Process by which MANRS standards are created and updated. This is the first document that was developed by the MANRS Development Process itself, which is a bottom-up, consensus driven, open policy development process. 

Introduction

For the MANRS initiative to produce documents that can be referenced and used as industry standard practices we need to follow a process that provides for open, accountable, and transparent decision-making.

This document defines the MANRS Development Process for such documents.

Special cases

Slightly modified versions of this process can be used for the development of other types of MANRS documents, such as the MANRS Community Charter and MANRS implementation guides. See Annex B. Special cases for more information.

Definitions¹

MANRS specifications and standards

A MANRS standard is a normative specification that documents the agreed requirements for “MANRS Actions”, and suggests approaches suitable for adoption and implementation by various parties and ensures consistency of their application. MANRS standards are mandatory for the MANRS participants. For other parties, a MANRS standard serves as  guidance that one party could expect of another in the context of internetworking. MANRS may also develop other informational, rather than normative, specifications, such as implementation guides, which are not required but may choose to follow the MANRS Development Process.

MANRS community (defined in the Charter)

The MANRS community is comprised of the (representatives of) MANRS participants, organizations and individuals supporting MANRS, its mission and objectives. The latter group can be technologists, researchers, members of civil society, and policymakers. Participation in the MANRS community is completely open, people can start participating by subscribing to the MANRS community mailing list. Participation in the MANRS community takes various forms, from a mailing list discussion, to virtual or hybrid events. People participate in the MANRS community activities in their personal capacity.

MANRS participants (defined in the Charter)

MANRS participants are organizations that have met and continue to meet the criteria as defined in MANRS documents and have been audited and approved by the MANRS secretariat.

MANRS participant’s representatives (defined in the Charter)

Natural persons that represent organizations that are MANRS participants. 

MANRS Steering Committee (SC) (defined in the Charter)

The MANRS Steering committee is a group that represents the MANRS participants and is comprised of individuals elected by the MANRS Participants and has responsibilities outlined in section 3 of the Charter.

Specific to the MDP, the SC has the following responsibilities:

• Is responsible for ratification of MANRS normative specifications.
• Serves as an appeal body for complaints of improper execution of the MANRS development process.

MANRS mailing lists 

While the development of a proposal can utilize various tools and communication channels, all major decisions, such as adoption of a document, declaration of consensus and approval must take place and be documented on a mailing list. 

Depending on a context, this could be an open mailing list, where anyone can subscribe to (for example a working group mailing list) or a closed mailing list, only available to MANRS participants. The open mailing lists have information about the list and the archives publicly available. Though a mailing list may be closed, it is not generally considered to be confidential.

MANRS Development Process (MDP)

The process by which MANRS standards are created. The process is based on remote participation, physical meetings can take place but are not essential. The MDP is consensus-based, applying a notion of a “rough consensus” explained in “On Consensus and Humming in the IETF”

The MDP

Based on requests by the community, MANRS may initiate development of a standard. 

Any MANRS community member may propose the inception of a standard. A working group (WG) will typically shepherd the standard. 

The MDP will follow the following phases. The description below documents the development of a new standard, and the same process applies for an update of an existing MANRS standard. 

Proposal for a new standard development 

• Suggestions for new standards, or revisions of existing MANRS standards are introduced as proposals. Any MANRS community member can propose the inception of a standard by submitting a proposal to the MANRS secretariat. Proposals are made using the Standard Proposal template, attached as Annex C. A slightly abbreviated process called “SDP-Lite” may be used in some circumstances as discussed further in Annex B.
  • Standard proposals are submitted to a [email protected], or using a submission form [url], which maps it to a tracking system. 
  • A proposal is assigned a unique name
  • An automatic acknowledgement is sent to the submitter.
• The secretariat will assess the proposal on relevance and technical quality. If necessary, the secretariat will work with the submitter in good faith to improve the proposal for clarity and formatting (1).  The MANRS secretariat will reject obvious SPAM, irrelevant and malformed proposals as input to further processing (11). This is a secretarial decision that can be appealed to the Steering Committee.
  • SPAM and malformed proposals will be discarded. Properly filled out proposals will be published with a status “Submitted” on a Proposals webpage. They will be assessed by the Secretariat and the submitter may be requested to make improvements regarding clarity and readability.  
• Upon positive decision the MANRS Secretarial will submit the proposal to the Steering Committee for consideration (2).
  • Upon sending the proposal to the Steering Committee (via the SC mailing list) the status of the proposal changes to “SC consideration”.

Announcement of new standard development

• The Steering Committee may decide to recharacterize the proposal from “Normative” to an “Informational”, or, if it does not believe the proposal is relevant or of sufficient quality, it may reject the proposal (9). This decision cannot be appealed.
  • The status of the proposal changes to “Rejected”. It remains published, along with the reasons for rejection.
• The Steering Committee may advance the proposal and decide to charter a working group (WG) to develop a new standard. 
• Once the WG is chartered, the development of a new standard is announced (3), and community members are invited to join the WG.
  • Proposal is announced. Status is changed to “Announced”. The link to the proposal page and the invitation to join the WG is at least sent to the “manrs-community” mailing list and announced on the MANRS website.
  • A WG space is created on the MANRS website, containing the WG charter, mailing list and other relevant information.

Development of a draft standard

• The WG will proceed with development of the draft standard according to its charter (4). The work will be conducted using an open mailing list, WG teleconferences and interim meeting as appropriate. All significant decisions have to be made and documented on the mailing list.

• Once the MANRS draft standard is developed, the WG will issue an internal Last Call for not less than 2 weeks for the WG members to respond. The Chair(s) will determine the consensus (5).
  • Status change to “WG Last Call”

• Where appropriate, the standard should be accompanied by the applicability document describing how the standard will be introduced and used in the context of MANRS.

• In case the consensus is achieved the MANRS draft standard will be progressed to the next phase.

Call for comments

• The WG chair(s) will submit the MANRS draft standard to the Steering Committee via the MANRS Secretariat.

• The Steering Committee will review and decide whether the MANRS draft standard can be progressed further, or whether further work is required in the WG. In the latter case the draft will be returned to the WG along with the reasons for such decision.

• In the case the specification progresses further, the MANRS Secretariat will announce the Call for comments on the MANRS draft standard (6).
  • The Call for comments will be announced at least on the MANRS web site, the manrs-community mailing list. Comments will be submitted to the manrs-community list. 

• The Call for comments will last at least 4 weeks. If the Steering Committee believes that the MANRS Community interest would be served by allowing more time for comment, it may decide on a longer Call for comments period or to explicitly lengthen a current Call for comments for comments period. 

• Upon completion of the Call for comments, the Steering Committee in consultation with the WG shall make a determination of whether the MANRS draft standard should undergo revision to address the comments or move towards the next phase – the MANRS Last Call. For informational specifications the MANRS Last Call is not necessary, and the specification can proceed to the last phase – “Ratification and publication of a standard”.

• If revision is deemed necessary, the WG will address received comments and present the draft to the Steering Committee for approval and publication (7). The Steering Committee may decide to issue another Call for comments to ensure that comments were sufficiently addressed. 

MANRS Last Call

Since the standard may have an immediate impact on the MANRS Participants, it is important to receive an explicit approval from them. The MANRS Last Call serves this purpose.

• The Steering Committee will instruct the MANRS Secretariat to announce the MANRS Last Call, open to the MANRS Participants (6’). The call will last for 2 weeks.
  • The MANRS Last Call for comments will be announced on the manrs-participants mailing list. Comments will be submitted to the manrs-participants list. 
• Upon completion of the MANRS Last Call, the Steering Committee shall make a determination of whether the MANRS draft standard can be ratified. 

Ratification and publication of a standard

• The Steering Committee will review and decide on the ratification of the standard (10).
• Upon the positive decision, the MANRS Secretariat will publish the standard on the MANRS website and announce the final release (8).
  • The standard will be announced at least on the MANRS web site manrs-participants and manrs-community mailing lists.
  • The MANRS Secretariat will evaluate opportunities for contributing the MANRS standard to external standard development organizations, industry associations, etc., such as ISO, ITU, FIRST, IETF, the RIRs, etc.
• The final standard must be marked with an [email protected] e-mail address for comments. 

Naming and version control

Each approved MANRS specification is published as part of the MANRS document series. The status field in the document indicates its type: normative for MANRS standards, such as MANRS Actions, and informational for supporting documentation, such as MANRS implementation guides. 

Approved MANRS specifications are assigned a unique name in a form MANRS-xxx.yy, where xxx is a number unique in the series and yy is the version number. The initial version of an approved specification “01”, and subsequent updates must increment the version number by one. Example: MANRS-003.01.

Each submitted proposal is assigned a unique name in a form YYYYMM-DRAFT-(subject).zz, where YYYY denotes the year and MM the month when the proposal was created or updated. The field “(subject)” describes the subject of the proposal in a few words. Each word is separated by a hyphen. zz is the version number. The initial version of a proposal is “01”, and subsequent updates must increment the version number by one.  Example 202411-DRAFT-netops-actions.01

Annex A. The requirements for the process and specifications

A general requirement is that the process of developing a specification should be aligned with the WTO Principles for the Development of International Standards, Guides and Recommendations. A practical translation of these requirements can be taken from a EU requirements for identification of tech specifications developed by consortia and fora (Annex II of Regulation 1025/2012 on European Standardisation). 

1. The Process should fulfill the following criteria:

(a) Openness

The MDP shall occur on the basis of open decision-making accessible to all interested parties in the market or markets affected by those technical specifications.

(b) Consensus

The decision-making process shall be collaborative and consensus based and not favoring 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. For the purposes of the MDP we use a description of a “rough consensus” explained in “On Consensus and Humming in the IETF”

(c) Transparency:

1. All information concerning technical discussions and decision making shall be archived and identified.
2. Information on new standardization activities shall be widely announced through suitable and accessible means.
3. Participation of all relevant categories of interested parties shall be sought with a view to achieving balance.
4. Consideration and response shall be given to comments by interested parties.

2. The MANRS normative specification itself must meet the following requirements:

(a) Maintenance

Ongoing support and maintenance of published specifications shall be guaranteed over a long period. This includes a well-defined publication series, document versioning and identification.

(b) Availability

Specifications shall be publicly available for implementation and use on reasonable terms (including for a reasonable fee or free of charge).

(c) Intellectual property rights essential to the implementation of standards/specifications shall be licensed to applicants on a (fair) reasonable and non-discriminatory basis ((F)RAND), which includes, at the discretion of the intellectual property right-holder, licensing essential intellectual property without compensation.

(d) Relevance

1. The specification shall be effective and relevant.
2. Specifications shall need to respond to market needs and regulatory requirements.

(e) Neutrality and stability

1. Specifications whenever possible shall be based on performance rather than based on design or descriptive characteristics.
2. Specifications shall not distort the market or limit the possibilities for implementers to develop competition and innovation based upon them. 
3. Standards shall be based on advanced scientific and technological developments.

(f) Quality

1. The quality and level of detail shall be sufficient to permit the development of a variety of competing implementations of interoperable products and services.
2. Standardized interfaces shall not be hidden or controlled by anyone other than the organizations that adopted the technical specifications.

Annex B. Special cases

There are circumstances that the process may deviate from the one described in the document (the baseline process) and there may be situations when additional processes need to be put in place. These cases are as follows:

1. MDP without a WG formation (MDP-lite)

In some cases, the proposal or the proposed changes to the existing standards are well understood and formed, so there is no need for a WG. In such cases the Secretariat and the SC can work together on a draft proposal, which can be announced (3) and submitted for the Call for comments (6) at the same time. The rest of the steps are intact. This path is marked in blue on fig 2.

2. Review and amendment of the MDP itself

This should follow the existing MDP or MDP-lite.

3. Handling of technical and editorial errata

The MDP uses the process of handling of technical and editorial errata based on the one used in the IETF, see “IESG Processing of RFC Errata for the IETF Stream” https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/. The process differs in two aspects:

• The responsibilities of the IESG will be handled by the MANRS Steering Committee
• The reported mistakes will be corrected in the specification along with referencing the errata report.

Appendix C: Standard proposal template

1. Name DRAFT-(subject).01 (assigned by the Secretariat)
2. Standard Proposal Name:
3. Author Details
   1. name:
   2. email:
   3. organization:
4. Submission Date:
5. Specification Type: Normative or Informational
6. Proposal Type:
   1. new, update or deletion
7. Summary of Proposal
8. Rationale:
   1. Motivation for the proposal
   2. Arguments supporting the proposal
   3. Arguments opposing the proposal
9. Text of the specification
   1. Text of the current specification (if modification):
   2. New text

Footnotes

1.  Definitions that are supposed to be documented in the Charter are provided here for information purposes only. Once the Charter is updated, they will be replaced with references to the Charter or removed altogether. ↩︎