Catalog
method#Governance#Architecture#Integration#Software Engineering

Request for Comments (RFC)

A formalized process for proposing, reviewing and publishing technical specifications and standards.

The Request for Comments (RFC) method formalizes how technical specifications, protocols and community standards are proposed, reviewed and published.
Established
Medium

Classification

  • Medium
  • Technical
  • Architectural
  • Intermediate

Technical context

Issue tracker (e.g., GitHub/GitLab) for feedbackCI/CD for interoperability testsDocumentation portals and archival systems

Principles & goals

Transparency through public documentation and discussion.Versioning and traceability for every change.Neutrality: technical arguments prioritized over organizational preferences.
Discovery
Enterprise, Domain, Team

Use cases & scenarios

Compromises

  • Excessive formality can stifle innovation.
  • Insufficient adoption despite published RFCs.
  • Conflicts between community feedback and company objectives.
  • Back decisions with implementations and tests.
  • Document migration paths and backward compatibility clearly.
  • Use standardized templates and metadata for RFCs.

I/O & resources

  • Draft specification or Internet-Draft
  • Implementation prototypes and tests
  • Stakeholder feedback and compatibility requirements
  • Published RFC with reference number
  • Review record and change log
  • Migration and implementation recommendations

Description

The Request for Comments (RFC) method formalizes how technical specifications, protocols and community standards are proposed, reviewed and published. It defines roles, editorial workflows, versioning and consensus mechanisms to ensure openness and traceability. RFCs are used as reference documents for interoperable open protocols.

✔

  • Clear, citable reference for implementers.
  • Promotes interoperability and long-term compatibility.
  • Structured review and governance processes increase quality.

✖

  • Publication cycles can be slow.
  • Requires moderation and formal roles that consume resources.
  • Potential inertia when product changes are rapid.

  • Time-to-Publish

    Time from submission to publication of an RFC; indicates process speed.

  • Adoption rate

    Percentage of relevant implementations that follow the RFC specification.

  • Number of review cycles

    Average number of review iterations until stabilization.

HTTP/1.1 (RFC 2616)

An RFC that defined core behavior of the HTTP protocol and was widely implemented.

OAuth 2.0 (RFC 6749)

A standards specification for delegation and authorization produced through the RFC process.

IPv6 (RFC 8200)

A comprehensive protocol standard RFC with long-term implementation and interoperability testing.

1

Formulate a precise draft as an Internet-Draft or internal document.

2

Conduct implementation and interoperability tests.

3

Organize review rounds, collect feedback and iterate until publication.

⚠️ Technical debt & bottlenecks

  • Old RFCs without migration guidance block further evolution.
  • Missing test suites for legacy specifications.
  • Inconsistent documentation formats hinder automation.
Decision makingResources for reviewsCoordination of external stakeholders
  • Using the RFC process as mere marketing without technical validation.
  • Publishing incompatible changes without a migration plan.
  • Ignoring external implementers during review.
  • Underestimated effort for moderation and governance.
  • Assuming publication immediately leads to adoption.
  • Lack of versioning causes implementer confusion.
Technical protocol designModeration and stakeholder managementExperience with versioning and release management
Interoperability between implementationsStability and backward compatibilityTransparent change and versioning rules
  • • Required moderation and formal roles
  • • Compatibility requirements of legacy implementations
  • • Organizational disclosure policies