methodatlas
Method guideArchitecture

Request for Comments

A practical method guide: clarify prerequisites and materials, understand the complete process, and look up outputs, pitfalls, and stop criteria.

ComplexityMedium
Time1-3 Wochen vom Draft bis zur Entscheidung
Participants3-20 Reviewer
FormatAsync
MaturityEstablished
Plan Request for Comments (RFC)
01

Prerequisite

What needs to be finished first

Complete firstBounded subject

The scope and purpose of Request for Comments (RFC) are stated as a concrete question.

Without scope, RFC record becomes arbitrary.
Complete firstAccess to relevant perspectives

Problem and constraints, design draft and alternatives, reviewers and decision owner and domain decision makers are available.

Without these perspectives, central claims in RFC record remain unsupported.
02

Preparation

What needs to be ready before start

Materials

Problem and constraints, design draft and alternatives, reviewers and decision owner, shared workspace, source links, and decision log.

People / roles

Author · reviewers · decision owner · affected implementers

Pre-read

Collect Problem and constraints, design draft and alternatives, reviewers and decision owner in advance and mark open assumptions.

Time needed

2–10 working days by consequence

Setup

Prepare versioned proposal with open review window, resolved comments, and explicit status visibly and calibrate assessment terms before starting.

03

Core question

The one question this method answers

Is the proposal decision-ready with alternatives, consequences, and a migration path?

04

Flow

Phases with goal, actions, output and pitfall

An internal RFC borrows the idea of open technical discussion but is not the IETF standards process. Problem, context, goals, non-goals, design, alternatives, risks, migration, and decision log are defined locally.

RFC record

Fictional worked example

versioned proposal with open review window, resolved comments, and explicit status as a precise working structure with a fictional example.

Problem/goals

Problem/goals information to record

Schema Evolution; kein neuer Broker.

Proposal/alternatives

Proposal/alternatives information to record

CloudEvents+JSON Schema vs. Avro.

Review/decision

Review/decision information to record

Security-Einwand beantwortet; Accepted.

Migration/status

Migration/status information to record

30 Tage Dual Publish; Implementing separat.

The example demonstrates the domain logic of Request for Comments (RFC); worksheets remain blank.

IETF RFC 2026: The Internet Standards Process

  1. 1

    Draft

    Draft

    Goal

    Produce RFC draft so the core question “Is the proposal decision-ready with alternatives, consequences, and a migration path?” can be answered with stronger support.

    Inputs for this step

    • Problem and constraints
    • design draft and alternatives
    • reviewers and decision owner

    Actions

    • Write problem, goals, non-goals, proposal, alternatives, and migration.
    • Record source, rationale, and open uncertainty directly in RFC draft.

    Output

    RFC draft

    RFC draft · source · uncertainty · next decision

    Quality check

    Are trade-offs included rather than only benefits?

    Pitfall

    The RFC is written after the decision or Accepted is confused with implemented. Open review before decision, record comment resolution, and track Accepted, Implementing, and Superseded separately.

    Timing: 10–20 minutes

  2. 2

    Review

    Review

    Goal

    Produce review record so the core question “Is the proposal decision-ready with alternatives, consequences, and a migration path?” can be answered with stronger support.

    Inputs for this step

    • RFC draft
    • design draft and alternatives
    • reviewers and decision owner

    Actions

    • Invite affected reviewers with a deadline and collect comments.
    • Record source, rationale, and open uncertainty directly in review record.

    Output

    review record

    review record · source · uncertainty · next decision

    Quality check

    Are Security, Operations, and consumers represented?

    Pitfall

    The RFC is written after the decision or Accepted is confused with implemented. Open review before decision, record comment resolution, and track Accepted, Implementing, and Superseded separately.

    Timing: 10–20 minutes

  3. 3

    Decision

    Decision

    Goal

    Produce RFC decision so the core question “Is the proposal decision-ready with alternatives, consequences, and a migration path?” can be answered with stronger support.

    Inputs for this step

    • review record
    • design draft and alternatives
    • reviewers and decision owner

    Actions

    • Resolve comments and have the decision owner decide with rationale.
    • Record source, rationale, and open uncertainty directly in RFC decision.

    Output

    RFC decision

    RFC decision · source · uncertainty · next decision

    Quality check

    Is every material objection addressed?

    Pitfall

    The RFC is written after the decision or Accepted is confused with implemented. Open review before decision, record comment resolution, and track Accepted, Implementing, and Superseded separately.

    Timing: 10–20 minutes

  4. 4

    Lifecycle

    Lifecycle

    Goal

    Produce RFC lifecycle so the core question “Is the proposal decision-ready with alternatives, consequences, and a migration path?” can be answered with stronger support.

    Inputs for this step

    • RFC decision
    • design draft and alternatives
    • reviewers and decision owner

    Actions

    • Track implementation, deviations, and supersession separately.
    • Record source, rationale, and open uncertainty directly in RFC lifecycle.

    Output

    RFC lifecycle

    RFC lifecycle · source · uncertainty · next decision

    Quality check

    Does status reflect reality?

    Pitfall

    The RFC is written after the decision or Accepted is confused with implemented. Open review before decision, record comment resolution, and track Accepted, Implementing, and Superseded separately.

    Timing: 10–20 minutes

05

Artifact

What comes out at the end

Sketch: what the artifact looks like

Request for Comments · Decide in Writing and ReviewablyConnect context, proposal, trade-offs, and comments into a traceable decision artifact
Kontext -> Proposal -> Trade-offs -> CommentsEin Änderungsvorschlag wird schriftlich prüfbar, kommentierbar und entscheidungsfähig.Kontext bis EntscheidungEin Änderungsvorschlag wird schriftlich prüfbar, kommentierbar und entscheidungsfähig.schriftlich denkenReview vor CommitDecision LogKontextProblem, Motivation, ScopeProposalkonkreter LösungsvorschlagTrade-offsAlternativen und RisikenCommentsReview und offene FragenEntscheidungaccepted, revised oder rejected mit nachvollziehbarer Spur
Form

Versioned RFC record with date, sources, owners, and next review.

Versioning / ownership

Retain date, source, assumption state, and decision for every version of RFC record.

Tool alternatives
  • RFC record as board or document
  • Source and evidence register
  • Decision and action log

rfc-working-template.md

Plan Request for Comments (RFC) around its domain steps and the concrete decision question.

Request for Comments: Worksheet

Question

To be confirmed

Desired outcome

To be confirmed

Scope

Establish and review the practice Time: 2–10 working days by consequence

Complete this worksheet on paper or in your own document during the work.

Preparation for this scope

Method setup

  • Materials: Problem and constraints, design draft and alternatives, reviewers and decision owner, shared workspace, source links, and decision log.
  • Roles: Author · reviewers · decision owner · affected implementers
  • Advance information: Collect Problem and constraints, design draft and alternatives, reviewers and decision owner in advance and mark open assumptions.
  • Overall time needed: 2–10 working days by consequence
  • Setup: Prepare versioned proposal with open review window, resolved comments, and explicit status visibly and calibrate assessment terms before starting.

Prepare for the work steps

Draft: Draft

  • Problem and constraints
  • design draft and alternatives
  • reviewers and decision owner

Review: Review

  • RFC draft
  • design draft and alternatives
  • reviewers and decision owner

Decision: Decision

  • review record
  • design draft and alternatives
  • reviewers and decision owner

Lifecycle: Lifecycle

  • RFC decision
  • design draft and alternatives
  • reviewers and decision owner

RFC record

Problem/goals

Problem/goals information to record

...

Proposal/alternatives

Proposal/alternatives information to record

...

Review/decision

Review/decision information to record

...

Migration/status

Migration/status information to record

...

Enter only real input, sources, and decisions.

IETF RFC 2026: The Internet Standards Process

Draft: Draft

Expected artifact: RFC draft

RFC draft · source · uncertainty · next decision

Entry:

...

  • Are trade-offs included rather than only benefits?

Review: Review

Expected artifact: review record

review record · source · uncertainty · next decision

Entry:

...

  • Are Security, Operations, and consumers represented?

Decision: Decision

Expected artifact: RFC decision

RFC decision · source · uncertainty · next decision

Entry:

...

  • Is every material objection addressed?

Lifecycle: Lifecycle

Expected artifact: RFC lifecycle

RFC lifecycle · source · uncertainty · next decision

Entry:

...

  • Does status reflect reality?

Open questions and next steps

...

Method guide: https://methodatlas.meierhoff-systems.de/en/methods/rfc/run-sheet

06

Example output

Concrete filled scenario, fictional example

Fictional example for orientation. Counts and timings describe this case and are not universal requirements.

rfc-beispiel.md

Concrete filled scenario, fictional example

RFC-042: versioned domain events. Goals: schema evolution and replay; non-goal: new broker. Proposal: CloudEvents envelope plus JSON Schema Registry. Alternatives: proprietary envelope, Avro. Migration: dual publish for 30 days. Status: Accepted 2026-10-15; decision log resolves the security objection.

07

Pitfalls

Recognize symptoms and steer against them

Quick overview, the full text is in the matching phase in the flow

  1. DraftThe RFC is written after the decision or Accepted is confused with implemented.View in phase
  2. ReviewThe RFC is written after the decision or Accepted is confused with implemented.View in phase
  3. DecisionThe RFC is written after the decision or Accepted is confused with implemented.View in phase
  4. LifecycleThe RFC is written after the decision or Accepted is confused with implemented.View in phase
08

Stop criteria

When to pause, resolve prerequisites, or choose another approach

RFC record answers the core question with traceable evidence or explicitly marked uncertainty.
Owners, next actions, and review dates are named for open points.

Method after Internet Engineering Task Force. Curated with 1 sources.

Sources: IETF RFC 2026: The Internet Standards Process

Flow, timeboxes, and pitfalls are editorially curated practice recommendations based on the listed sources.

Where to go next?

Paper illustration of two considered options leading to a decision record with a marked status and visible consequences.
Architecture
Architecture Decision Record

Anchors the decision accepted in the RFC as a lasting architecture decision.

Paper illustration for Communication Plan
Delivery
Communication Plan

Communicates the accepted change to affected teams and reviewers.

View in playbookSafeguard Architecture Quality Before ImplementationMove from the guardrails of an architecture initiative through prioritized quality scenarios to a solution put up for review.

Finished the method guide?

Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.

Go to profileMore methods