1/COSS: New RFC Process #4
Conversation
There was a problem hiding this comment.
Thank you!
I left some comments inline.
Generally, we need to be more explicit about the new process, especially about the fact that "raw" lives outside of Vac's responsibility.
Mention something like:
- project teams write raw specifications for their protocols and components.
The Vac RFC team may be involved in this stage already and can support writing first drafts. - when these specifications reach a certain level of maturity they enter the Vac RFC process and become RFC drafts;
this step corresponds to working group adoption in the IETF [please cite IEFT working group adoption here, linking to an IEFT document explaining this.]
We should explain that the rigorous process described in the COSS starts with a document becoming draft / getting a number.
(you have some explanation on this in the COSS already, you can merge your text with this) - explain the process from draft to stable...
you can also add that this iterative process helps identify and fix design and implementation flaws.
| New versions of the same specification will have new numbers. | ||
| The syntax for a specification reference is: | ||
|
|
||
| <domain>/spec/<number>/<shortname> | ||
| <domain>/project/<number>/<shortname> |
There was a problem hiding this comment.
We should mention that setting vac as he project means the RFC is more generally applicable and not specific to one project. Vac is not a project.
vac/1/coss.md
Outdated
|
|
||
| A specification has six possible states that reflect its maturity and contractual weight: | ||
| For a specification to receive a lifecycle status, | ||
| a new specification SHOULD be presented by the project team. |
There was a problem hiding this comment.
What is a project team? That term has not been introduced yet.
We should also introduce the concept of an IFT project before.
We should also mention that non-project applications are accepted, too. We should keep the process open to the whole community not limit it to IFT. We could add such applications to vac for now.
vac/1/coss.md
Outdated
| A specification has six possible states that reflect its maturity and contractual weight: | ||
| For a specification to receive a lifecycle status, | ||
| a new specification SHOULD be presented by the project team. | ||
| After discussion amongst the contributors has occurred for an unspecific amount of time, |
There was a problem hiding this comment.
| After discussion amongst the contributors has occurred for an unspecific amount of time, | |
| After discussion amongst the contributors has reached rough consensus, |
Ideally cite the IETF for the definition of rough consensus.
Making changes to COSS to reflect new RFC process.