You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
captainfffsama
1297acf91b
|
2 years ago | |
---|---|---|
.. | ||
README.md | 2 years ago | |
XRFC-TEMPLATE.md | 2 years ago |
README.md
xDS RFCs (xRFCs)
Introduction
This directory contains the design proposals for substantial feature changes for xDS. The goal of this process is to:
- Provide a reference for the xDS transport protocol and data model standards.
- Capture design history and tradeoffs as the xDS APIs evolve.
- Provide increased visibility to the community on upcoming changes and the design considerations around them.
- Provide ability to reason about larger “sets” of changes that are too big to be covered either in an Issue or in a PR.
- Establish a consistent process for structured participation by the community on significant changes, especially those that impact multiple clients and servers.
We have modeled the xRFC process on gRPC RFCs.
Process
- Copy the template XRFC-TEMPLATE.md.
- Rename it to
$CategoryName$xRfcId-$Summary.md
, e.g.TP1-xds-transport-next.md
(see category definitions below). The$xRfcId
should be strictly higher than any existing or under-review xRFC in$CategoryName
. - Write up the RFC.
- Submit a Pull Request. The CNCF xDS working group should be tagged with
@cncf/xds-wg
and an e-mail sent toxds-wg@lists.cncf.io
linking to the PR. All discussion is expected to take place within the PR. - An APPROVER will be assigned by one of this repository's maintainers.
- For at least a period of 10 business days (the minimum comment period), it is expected that the OWNER will respond to the comments and make updates to the RFC as new commits to the PR. Through the process, the discussion should take place within the PR to avoid splintering conversations. The OWNER is encouraged to solicit as much feedback on the proposal as possible during this period.
- If there is consensus as deemed by the APPROVER during the comment period, the APPROVER will merge the proposal pull request.
Proposal Categories
The proposals shall be numbered in increasing order.
#TPn
- Transport protocol.#DMn
- Data model.#Pnn
- Affects processes, such as the proposal process itself.
Proposal Status
- Every uncommitted proposal is effectively in draft status.
- Once committed, a proposal is in finalized status.
- If issues are discovered during implementation, revisions may be made by following the review process.
- Once implemented by an xDS client, this should be reflected in the
Implemented in:
header field of the proposal. Listing versions is not required.