Writing RFC Documents: Language for Proposing Technical Changes
5 exercises — writing RFC problem statements, motivation sections, alternatives considered, drawbacks sections, and open questions.
0 / 5 completed
1 / 5
You are writing the Problem Statement section of an RFC. Which version is MOST effective?
RFC problem statements must be specific: state what is broken, why it is broken, and what impact it has. Option B describes the mechanism (session not shared across instances), the symptom (users logged out), and the impact (blocks scaling). Option A is vague. Option C is a solution, not a problem. Option D avoids committing to anything.
2 / 5
An RFC's Motivation section should explain:
RFC Motivation section answers 'why now?' and 'what are we trying to achieve?'. It is distinct from the Problem Statement (which describes what is broken) and from Alternatives (which comes later). Motivation provides the strategic context: business drivers, user impact, or technical debt that makes action necessary.
3 / 5
An RFC's 'Alternatives Considered' section reads: 'We also evaluated sticky sessions at the load balancer level. This would solve the immediate scaling problem but introduces a single point of failure and uneven load distribution, making it unsuitable for our reliability goals.' This is a good alternatives entry because:
Alternatives Considered entries should follow the pattern: (1) name the alternative, (2) acknowledge its merit, (3) explain the specific reason it was rejected. This shows intellectual honesty and helps future readers understand why the chosen approach was preferred — not just that it was.
4 / 5
Which sentence is BEST suited for an RFC's Drawbacks section?
RFC Drawbacks sections require candid, specific acknowledgement of real downsides. Option B names a concrete technical limitation (JWTs are stateless, so revocation requires extra infrastructure). Listing genuine drawbacks builds trust with reviewers — an RFC with no drawbacks looks unconvincing.
5 / 5
An RFC's Open Questions section should contain:
Open Questions in RFCs are honest signals of uncertainty — areas where the author does not yet have a definitive answer. Examples: 'Should we use RS256 or HS256 for signing?', 'What is the token expiry policy for mobile clients?' These invite reviewers with relevant expertise to contribute, making the RFC a collaborative document.