AIO logo
Public RFC Process

AIO Public RFC Process

The public process through which standards, specifications, policies, and process changes are proposed, reviewed, and adopted.

AIO Public RFC Process

1) Purpose and Scope

This document defines the AIO Public Request For Comment (RFC) procedure for proposing standards, specifications, and process changes. It covers the types of RFCs, stages of progression, submission and numbering conventions, licensing, review responsibilities, and related governance practices.

The RFC process is intended to create an open, auditable record of technical and process proposals that stakeholders across the ecosystem can review and implement.

2) Document Types

  • Standards Track: Specifications that define normative formats, behaviors, or APIs (examples: RBP JSON, BYOR API).
  • Informational: Guidance, background, use-cases, or explanatory material.
  • Process: Proposals that change organizational or procedural rules.

3) Status Progression

RFCs progress through the following lifecycle: Idea → Draft → Candidate (CR) → Final (STD) → Deprecated.

  • Draft: Public review period begins (minimum 14 days).
  • Candidate: Implementation and interoperability verification; readiness review (minimum 30 days).
  • Final: Ratified following consensus and applicable governance approvals.
  • Deprecated: Marked when superseded or removed from recommended use.

4) Numbering and Metadata

  • RFC Identifier: AIO-RFC-YYYY-NNN (e.g., AIO-RFC-2025-001).
  • Required metadata: title, abstract, motivation, specification, rationale, compatibility considerations, security/privacy considerations, implementation notes, IPR/licensing, referenced documents, change log, and author list.
  • Licensing: document text under CC BY 4.0; code samples under Apache-2.0 or MIT.

5) Submission and Publication

  • Submission methods: GitHub issue/PR or an official submission mechanism designated by AIO (public-first preferred).
  • All artifacts (text, reference implementations, test vectors) must be published in a public repository where practicable to aid review and reproducibility.

6) Review and Decision Roles

  • Reviewers: Subject-matter experts and working groups provide technical review and verification of claims.
  • Working Group (WG): Responsible for shepherding proposals through verification to candidate stage and for producing implementation guidance.
  • Community: Public discussion channels and issue threads are primary spaces for open review.

7) Review Durations and Revisions

  • Draft: minimum 14 days of public review.
  • Candidate: minimum 30 days for implementation verification (exceptions as approved).
  • Revisions are tracked with revision suffixes (e.g., -rev1, -rev2). Errata are published for minor corrections.

8) IPR and Licensing

  • Authors grant AIO the right to publish the document text under CC BY 4.0 and any reference code under Apache-2.0 or MIT, unless otherwise specified.
  • Contributors are expected to disclose any patent encumbrances; licensing commitments should be explicit in the RFC.

9) Editorial and Stewardship Roles

  • Editor-in-Chief: Overall editorial responsibility and publication authority for RFCs.
  • RFC Editor: Handles formatting, metadata, and maintaining the RFC index.
  • Working Groups: Provide technical review, test suites, and reference implementations where required.
  • Governance bodies may reserve authority for process-level decisions affecting RFC acceptance.

10) Timelines and Change Management

  • Standard timelines (Draft 14 days, Candidate 30 days) are the default; exceptions require documented justification.
  • Significant changes are managed with versioned releases and change logs; emergency fixes may be handled via errata.

11) IPR & Disclosure

  • Contributors must declare rights and licensing for contributed material. Where third-party rights exist, contributors should explain the status and permissions.

12) Appending and Working Group Submissions

  • RFCs may be authored or sponsored by AIO working groups, committees, or by individual contributors. Working groups should produce review artifacts and reference implementations where applicable.

13) Revisions

  • Revisions are recorded in the document changelog. Major revisions should include a summary of changes and motivation.

14) Governance Integration

  • RFCs that affect organizational rules or statutes may require review and approval by the appropriate governance body (e.g., General Assembly, Board).

15) Conflict of Interest and Recusal

  • Contributors and reviewers must disclose conflicts of interest. Where conflicts affect a decision, recusal or other mitigations will be applied.

16) Data Protection and Privacy

  • Where RFCs involve personal data, privacy impact assessments or DPIAs should be conducted and documented.

17) Publication Norms

  • RFCs are published openly; metadata and version history are retained to ensure traceability.

18) Licensing

  • Document text: CC BY 4.0.
  • Source code and test artifacts: Apache-2.0 or MIT.

19) Enforcement and Compliance

  • The AIO staff and relevant working groups are responsible for ensuring publication and archival practices are followed.

20) Governance Decisions

  • Governance-level decisions (e.g., adoption of an RFC as a formal standard) follow voting rules specified in the statutes and may require supermajorities.

21) Adoption and Implementation

  • The working group or sponsoring body is responsible for coordinating implementation and monitoring adoption; major decisions should be recorded and published.

<sub>Final v1.0</sub>

AIO Public RFC Process | AIO