IMPORTANT: Fill in and remove all italicized text before submission. If a section is not applicable, remove it.
| Status | Proposed, Accepted, Implemented, Obsolete |
| RFC # | Update after PR has been made |
| Author(s) | (@<my-github>), (@another-github) |
| SIG / WG | Applicable SIG(s) or Working Group(s) |
| Obsoletes | <RFC-#s>, if any, or remove header |
If someone only reads this far, what do you want them to know?
What problems are you trying to solve? What problems are not not trying to solve?
What is the current state of the world? Why is this change being proposed? What are the benefits for users (end-users, engineers, operators, etc.)? Who have you identified as early customers of this change?
What is the proposed timeline for the implementation? This timeline should encompass the entire scope of the project, not just the initial merge of the code. If applicable, it should include when the feature will be ready for testing by potential customers, when you will address their feedback, and when the code will be considered production-ready.
What exactly are you doing? What is this change being proposed?
This is typically the longest part of the RFC.
What existing internal and external systems does this proposal depend on? Are any new dependencies (libraries or systems) being introduced?
Why should we not do this?
What other approaches did you consider? What existing solutions are close but not quite right? How will this project replace or integrate with the alternatives?
What parts of the design do you expect to resolve through the RFC process? What parts of the design do you expect to resolve through implementation before stabilization? What related issues do you consider out of scope for this RFC that could be addressed in the future?
What security/privacy/compliance aspects should be considered?
If you are not certain, never assume there aren't any. Always talk to the Security SIG or Technical Oversight Committee.
Are you adding any new, regular human processes, or extra work for any users? What telemetry is needed to verify correct behavior? What tooling needs to be introduced for on-going support?
What known risks exist? What factors may complicate your project?
Include: security, complexity, compatibility, latency, service immaturity, lack of team expertise, etc.
What are the natural extensions and evolution of this RFC that would affect the project as a whole?
Feel free to dump ideas here, they're meant to get wheels turning, and won't affect the outcome of the approval process.