In this post, I’d like to provide an overview of the IFT/Vac RFC process and invite discussion or input.
The primary goal of this process is to establish a specification process modeled after the IETF’s approach (IETF | Internet standards process). In this model, IFT/Vac acts similarly to the IETF, while IFT portfolio companies, independent contributors, and other entities take on the role of submitting specifications. These contributors resemble companies such as Google and Cloudflare, as well as universities and independent developers in the IETF ecosystem.
It’s important to note that RFCs should define the core protocols a project relies on, rather than serve as API specifications. For example, Google submitted the QUIC protocol to the IETF while maintaining the API specification for Chrome in their own repositories. Similarly, the Vac RFC process focuses on specifying the foundational protocols, leaving implementation details and specific APIs to be managed within project-specific repositories.
The objective is to consolidate specifications and guide them toward a unified, high-quality standard. Anyone can visit the Vac RFC page (rfc.vac.dev) to explore the protocols, implement the specifications, and develop components compatible with our projects—such as building a custom Waku node, for instance.
In addition to promoting openness by enabling anyone to implement the protocols, this approach strengthens the credibility of projects. Writing thorough specifications not only facilitates external contributions but also helps uncover bugs and identify potential design flaws in the protocols. Detailed specifications provide a clear, standardized framework for understanding how the system should behave, which allows for independent testing not based solely on the code itself, but on what the specifications define as the expected behavior. This leads to more robust, interoperable implementations and ultimately improves the overall quality of the project.
Our goals align closely with those of the IETF, which seeks:
The goals of the Internet Standards Process are:
* technical excellence;
* prior implementation and testing;
* clear, concise, and easily understood documentation;
* openness and fairness; and
* timeliness.
The goal of technical competence, the requirement for prior implementation and testing,
and the need to allow all interested parties to comment all require significant time and effort.
On the other hand, today's rapid development of networking technology demands timely development of standards.
The Internet Standards Process is intended to balance these conflicting goals.
The process is believed to be as short and simple as possible without sacrificing technical excellence, thorough testing before adoption of a standard, or openness and fairness.
To lower the barrier for projects and contributors, raw RFCs are maintained without imposing rigid structures. The Vac RFC team is available to assist in writing these, though teams may choose to draft them independently. Once a document reaches a sufficient level of maturity, it can enter the Vac RFC process, where it is openly developed (currently via pull requests to the Vac RFC index repository). The Vac RFC team ensures that:
- The specification is of high technical quality;
- It allows independent implementers to create interoperable implementations;
- It uses appropriate technical language;
- It includes relevant security considerations.
Once we have two independent, interoperable implementations that function in practice, and all criteria outlined above are met, the draft will be promoted to a stable RFC. At this stage, the RFC becomes fixed and will no longer be updated. However, a new version of the RFC can be introduced if needed, following the same process from the beginning.
This process mirrors the IETF’s draft review and iteration cycle within working groups. Vac will collaborate closely with the author throughout this phase, working towards the draft’s promotion to a stable RFC, and on subsequent versions as necessary.
To further support maintaining these standards and engaging contributors, we are considering introducing a structure similar to IETF working groups. Each IFT portfolio project could have its own working group, consisting of the IFT project steering committee, core contributors (CCs) from the portfolio projects, and any other interested participants. We plan to experiment with this concept during IFT offsites, focusing on core protocols. At each offsite, the aim would be to refine the RFC draft and move it closer to becoming a stable specification.
To ensure that project development is not hindered, teams can continue updating their raw specifications in parallel with the Vac RFC process. These raw specifications will reflect the most up-to-date state of the protocol. Periodically, these updates can be integrated into the Vac RFC draft once they have proven effective and efficient. Google’s QUIC protocol offers a useful comparison: Google maintained the most current documentation, while updates to the IETF RFC draft occurred at IETF meetings, where consensus on changes was achieved.