methodatlas
MethodenanleitungArchitecture

Request for Comments

Die Anleitung zur Methode: Voraussetzungen und Materialien klären, den gesamten Ablauf verstehen und Ergebnisse, Stolperfallen sowie Abbruchkriterien nachschlagen.

KomplexitätMittel
Zeit1-3 Wochen vom Draft bis zur Entscheidung
Teilnehmende3-20 Reviewer
FormatAsync
ReifegradEstablished
Request for Comments (RFC) planen
01

Vorbedingung

Was vorher fertig sein muss

Vorher abschließenBegrenzter Gegenstand

Scope und Zweck von Request for Comments (RFC) sind als konkrete Frage benannt.

Ohne Scope wird RFC Record beliebig.
Vorher abschließenZugang zu relevanten Perspektiven

Problem und Constraints, Designentwurf und Alternativen, Reviewer und Decision Owner und entscheidungsfähige Fachpersonen sind verfügbar.

Ohne diese Perspektiven bleiben zentrale Aussagen in RFC Record unbelegt.
02

Vorbereitung

Was vor Start vorliegen muss

Materialien

Problem und Constraints, Designentwurf und Alternativen, Reviewer und Decision Owner, gemeinsame Arbeitsfläche, Quellenlinks und Entscheidungslog.

Personen / Rollen

Author · Reviewers · Decision Owner · affected implementers

Vorabinfos

Problem und Constraints, Designentwurf und Alternativen, Reviewer und Decision Owner vorab zusammentragen und offene Annahmen markieren.

Zeitbedarf

2–10 Arbeitstage je Tragweite

Setup

versionierter Vorschlag mit offener Reviewfrist, adressierten Kommentaren und explizitem Status sichtbar vorbereiten und Bewertungsbegriffe vor Beginn kalibrieren.

03

Kernfrage

Die eine Frage, die diese Methode beantwortet

Ist der Vorschlag mit Alternativen, Folgen und Migrationsweg entscheidungsreif?

04

Ablauf

Phasen mit Ziel, Durchführung, Ergebnis und Stolperfalle

Ein interner RFC übernimmt die Idee offener technischer Diskussion, ist aber kein IETF-Standardprozess. Problem, Kontext, Ziele, Nicht-Ziele, Design, Alternativen, Risiken, Migration und Decision Log werden lokal verbindlich definiert.

RFC Record

Fiktives Arbeitsbeispiel

versionierter Vorschlag mit offener Reviewfrist, adressierten Kommentaren und explizitem Status als präzise Arbeitsstruktur mit fiktivem Beispiel.

Problem/Goals

Festzuhaltende Problem/Goals-Angaben

Schema Evolution; kein neuer Broker.

Proposal/Alternatives

Festzuhaltende Proposal/Alternatives-Angaben

CloudEvents+JSON Schema vs. Avro.

Review/Decision

Festzuhaltende Review/Decision-Angaben

Security-Einwand beantwortet; Accepted.

Migration/Status

Festzuhaltende Migration/Status-Angaben

30 Tage Dual Publish; Implementing separat.

Das Beispiel zeigt die Fachlogik von Request for Comments (RFC); eigene Vorlagen bleiben leer.

IETF RFC 2026: The Internet Standards Process

  1. 1

    Draft

    Draft

    Ziel

    RFC Draft so erarbeiten, dass die Kernfrage „Ist der Vorschlag mit Alternativen, Folgen und Migrationsweg entscheidungsreif?“ belastbar weiter beantwortet werden kann.

    Voraussetzungen für diesen Schritt

    • Problem und Constraints
    • Designentwurf und Alternativen
    • Reviewer und Decision Owner

    Durchführung

    • Problem, Ziele, Nicht-Ziele, Proposal, Alternativen und Migration schreiben.
    • Quelle, Begründung und offene Unsicherheit direkt in RFC Draft festhalten.

    Ergebnis

    RFC Draft

    RFC Draft · Quelle · Unsicherheit · nächster Entscheid

    Qualitätscheck

    Sind Trade-offs statt nur Vorteile enthalten?

    Stolperfalle

    Der RFC wird nach der Entscheidung geschrieben oder Accepted wird mit umgesetzt verwechselt. Review vor Entscheidung öffnen, Kommentarauflösung protokollieren und Status Accepted, Implementing, Superseded getrennt führen.

    Zeitlicher Rahmen: 10–20 Minuten

  2. 2

    Review

    Review

    Ziel

    Review Record so erarbeiten, dass die Kernfrage „Ist der Vorschlag mit Alternativen, Folgen und Migrationsweg entscheidungsreif?“ belastbar weiter beantwortet werden kann.

    Voraussetzungen für diesen Schritt

    • RFC Draft
    • Designentwurf und Alternativen
    • Reviewer und Decision Owner

    Durchführung

    • Betroffene Reviewer mit Frist einladen und Kommentare sammeln.
    • Quelle, Begründung und offene Unsicherheit direkt in Review Record festhalten.

    Ergebnis

    Review Record

    Review Record · Quelle · Unsicherheit · nächster Entscheid

    Qualitätscheck

    Sind Security, Operations und Consumer vertreten?

    Stolperfalle

    Der RFC wird nach der Entscheidung geschrieben oder Accepted wird mit umgesetzt verwechselt. Review vor Entscheidung öffnen, Kommentarauflösung protokollieren und Status Accepted, Implementing, Superseded getrennt führen.

    Zeitlicher Rahmen: 10–20 Minuten

  3. 3

    Decision

    Decision

    Ziel

    RFC Decision so erarbeiten, dass die Kernfrage „Ist der Vorschlag mit Alternativen, Folgen und Migrationsweg entscheidungsreif?“ belastbar weiter beantwortet werden kann.

    Voraussetzungen für diesen Schritt

    • Review Record
    • Designentwurf und Alternativen
    • Reviewer und Decision Owner

    Durchführung

    • Kommentare adressieren und Decision Owner mit Begründung entscheiden lassen.
    • Quelle, Begründung und offene Unsicherheit direkt in RFC Decision festhalten.

    Ergebnis

    RFC Decision

    RFC Decision · Quelle · Unsicherheit · nächster Entscheid

    Qualitätscheck

    Ist jeder wesentliche Einwand beantwortet?

    Stolperfalle

    Der RFC wird nach der Entscheidung geschrieben oder Accepted wird mit umgesetzt verwechselt. Review vor Entscheidung öffnen, Kommentarauflösung protokollieren und Status Accepted, Implementing, Superseded getrennt führen.

    Zeitlicher Rahmen: 10–20 Minuten

  4. 4

    Lifecycle

    Lifecycle

    Ziel

    RFC Lifecycle so erarbeiten, dass die Kernfrage „Ist der Vorschlag mit Alternativen, Folgen und Migrationsweg entscheidungsreif?“ belastbar weiter beantwortet werden kann.

    Voraussetzungen für diesen Schritt

    • RFC Decision
    • Designentwurf und Alternativen
    • Reviewer und Decision Owner

    Durchführung

    • Implementierung, Abweichungen und Supersession separat nachhalten.
    • Quelle, Begründung und offene Unsicherheit direkt in RFC Lifecycle festhalten.

    Ergebnis

    RFC Lifecycle

    RFC Lifecycle · Quelle · Unsicherheit · nächster Entscheid

    Qualitätscheck

    Spiegelt Status den realen Stand?

    Stolperfalle

    Der RFC wird nach der Entscheidung geschrieben oder Accepted wird mit umgesetzt verwechselt. Review vor Entscheidung öffnen, Kommentarauflösung protokollieren und Status Accepted, Implementing, Superseded getrennt führen.

    Zeitlicher Rahmen: 10–20 Minuten

05

Artefakt

Was am Ende rauskommt

Skizze: so sieht das Artefakt aus

Request for Comments · schriftlich prüfbar entscheidenKontext, Proposal, Trade-offs und Kommentare zu einem nachvollziehbaren Entscheidungsartefakt verbinden
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

Versioniertes RFC Record mit Datum, Quellen, Ownern und nächstem Review.

Versionierung / Ownership

Datum, Quelle, Annahmenstand und Entscheidung je Fassung von RFC Record erhalten.

Tool-Alternativen
  • RFC Record als Board oder Dokument
  • Quellen- und Evidenzregister
  • Entscheidungs- und Maßnahmenlog

rfc-working-template.md

Plane Request for Comments (RFC) entlang der fachlichen Schritte und der konkreten Entscheidungsfrage.

Request for Comments: Arbeitsvorlage

Fragestellung

Noch zu klären

Gewünschtes Ergebnis

Noch zu klären

Rahmen

Praxis einrichten und überprüfen Zeit: 2–10 Arbeitstage je Tragweite

Diese Vorlage während der Arbeit auf Papier oder in einem eigenen Dokument ausfüllen.

Vorbereitung für diesen Umfang

Methodische Grundausstattung

  • Materialien: Problem und Constraints, Designentwurf und Alternativen, Reviewer und Decision Owner, gemeinsame Arbeitsfläche, Quellenlinks und Entscheidungslog.
  • Rollen: Author · Reviewers · Decision Owner · affected implementers
  • Vorab-Infos: Problem und Constraints, Designentwurf und Alternativen, Reviewer und Decision Owner vorab zusammentragen und offene Annahmen markieren.
  • Gesamter Zeitbedarf: 2–10 Arbeitstage je Tragweite
  • Setup: versionierter Vorschlag mit offener Reviewfrist, adressierten Kommentaren und explizitem Status sichtbar vorbereiten und Bewertungsbegriffe vor Beginn kalibrieren.

Für die Arbeitsschritte bereitstellen

Draft: Draft

  • Problem und Constraints
  • Designentwurf und Alternativen
  • Reviewer und Decision Owner

Review: Review

  • RFC Draft
  • Designentwurf und Alternativen
  • Reviewer und Decision Owner

Decision: Decision

  • Review Record
  • Designentwurf und Alternativen
  • Reviewer und Decision Owner

Lifecycle: Lifecycle

  • RFC Decision
  • Designentwurf und Alternativen
  • Reviewer und Decision Owner

RFC Record

Problem/Goals

Festzuhaltende Problem/Goals-Angaben

...

Proposal/Alternatives

Festzuhaltende Proposal/Alternatives-Angaben

...

Review/Decision

Festzuhaltende Review/Decision-Angaben

...

Migration/Status

Festzuhaltende Migration/Status-Angaben

...

Nur reale Angaben, Quellen und Entscheidungen eintragen.

IETF RFC 2026: The Internet Standards Process

Draft: Draft

Erwartetes Artefakt: RFC Draft

RFC Draft · Quelle · Unsicherheit · nächster Entscheid

Eintrag:

...

  • Sind Trade-offs statt nur Vorteile enthalten?

Review: Review

Erwartetes Artefakt: Review Record

Review Record · Quelle · Unsicherheit · nächster Entscheid

Eintrag:

...

  • Sind Security, Operations und Consumer vertreten?

Decision: Decision

Erwartetes Artefakt: RFC Decision

RFC Decision · Quelle · Unsicherheit · nächster Entscheid

Eintrag:

...

  • Ist jeder wesentliche Einwand beantwortet?

Lifecycle: Lifecycle

Erwartetes Artefakt: RFC Lifecycle

RFC Lifecycle · Quelle · Unsicherheit · nächster Entscheid

Eintrag:

...

  • Spiegelt Status den realen Stand?

Offene Fragen und nächste Schritte

...

Methodenanleitung: https://methodatlas.meierhoff-systems.de/de/methods/rfc/run-sheet

06

Beispielausgabe

Konkret gefülltes Szenario, fiktives Beispiel

Fiktives Beispiel zur Orientierung. Die genannten Mengen und Zeiten beschreiben diesen Fall und sind keine allgemeine Vorgabe.

rfc-beispiel.md

Konkret gefülltes Szenario, fiktives Beispiel

RFC-042: Versioned Domain Events. Goals: schema evolution und replay; Non-goal: neuer Broker. Proposal: CloudEvents envelope plus JSON Schema Registry. Alternatives: proprietärer Envelope, Avro. Migration: dual publish 30 Tage. Status: Accepted 2026-10-15; Decision Log beantwortet Security-Einwand.

07

Stolperfallen

Symptome erkennen, gegensteuern

Kurzüberblick, vollständiger Text steht in der jeweiligen Phase im Ablauf

  1. DraftDer RFC wird nach der Entscheidung geschrieben oder Accepted wird mit umgesetzt verwechselt.In der Phase ansehen
  2. ReviewDer RFC wird nach der Entscheidung geschrieben oder Accepted wird mit umgesetzt verwechselt.In der Phase ansehen
  3. DecisionDer RFC wird nach der Entscheidung geschrieben oder Accepted wird mit umgesetzt verwechselt.In der Phase ansehen
  4. LifecycleDer RFC wird nach der Entscheidung geschrieben oder Accepted wird mit umgesetzt verwechselt.In der Phase ansehen
08

Abbruchkriterien

Wann du anhalten, Voraussetzungen klären oder einen anderen Ansatz wählen solltest

RFC Record beantwortet die Kernfrage mit nachvollziehbaren Belegen oder offen markierter Unsicherheit.
Owner, nächste Aktion und Prüftermin sind für offene Punkte benannt.

Methode nach Internet Engineering Task Force. Kuratiert mit 1 Quellen.

Quellen: IETF RFC 2026: The Internet Standards Process

Ablauf, Timeboxen und Stolperfallen sind redaktionell kuratierte Praxisempfehlungen auf Basis der genannten Quellen.

Wie geht es weiter?

Papierillustration mit zwei betrachteten Optionen, die zu einem Entscheidungsdokument mit markiertem Status und sichtbaren Konsequenzen führen.
Architecture
Architecture Decision Record

Verankert die im RFC akzeptierte Entscheidung als dauerhaften Architekturentscheid.

Papierillustration zu Communication Plan
Delivery
Communication Plan

Kommuniziert die akzeptierte Änderung an betroffene Teams und Reviewer.

Im Playbook ansehenArchitekturqualität vor Umsetzung absichernVon den Leitplanken einer Architekturinitiative über priorisierte Qualitätsszenarien zu einer zur Diskussion gestellten Lösung.

Methodenanleitung durchgearbeitet?

Zum Steckbrief für Zweck, ähnliche Methoden und Quellen oder direkt zur nächsten Methode im Katalog.

Zum SteckbriefWeitere Methoden