Merge pull request #15 from mcy/rfc-templates

Add a basic RFC template for extending the protocol

Author: mcy

RoT/Protocol/RFCs/0000-RFC_Template.md

@@ -0,0 +1,48 @@
+* Name: Unique identifier for the proposal
+* Date: YYYY-MM-DD
+* Pull Request: [#NNNN](https://github.com/opencomputeproject/Security/pull/NNNN)
+
+# Objective
+
+A summary of the problem this proposal intends to solve, along with background.
+
+# Proposal
+
+A technical description of how this proposal achieves the goals outlined above.
+For example, this may include the introduction of new concepts, protocol
+messages, and so on.
+
+This section should explain the proposal in detail, but should not describe how
+to achieve it in code or in standardsese; that is a task for the sections that
+follow.
+
+# Specification Changelist
+
+A list of proposed changes to the specification(s) relevant to this proposal.
+This should not be an actual diff of the specs; merely a description of the changes
+to be made once the RFC is adopted.
+
+If this RFC would introduce an entirely new spec document, describing the broad
+strokes of what that document would contain is sufficient.
+
+# Implementation Guidance
+
+This section is optional.
+
+For proposals which introduce significant complexity w.r.t. implementation of
+the protocol, this section can give a brief description of how the proposal
+might be implemented.
+
+# Alternatives Considered
+
+This section is optional.
+
+Proposals may choose to include alternative approaches to solving their stated
+problem, and why those were rejected in favor of the main one.
+
+# Future Work
+
+This section is optional.
+
+Proposals may describe future RFCs that solve related, but out-of-scope
+problems.

RoT/Protocol/RFCs/README.md

@@ -0,0 +1,36 @@
+# Cerberus RFCs
+
+Proposals for improving the Cerberus specifications are handled through the RFC
+process. An RFC describes a problem with the protocol as it exists today and
+proposes a solution.
+
+Unlike IETF RFCs, Cerberus RFCs are non-normative, and primarily exist to record
+discussions leading to particular design decisions in the protocol, and to
+provide a starting point for deciding whether to adopt a proposal.
+
+## Creating an RFC
+
+Creating an RFC is done as follows:
+1. Pick a name for the RFC, say, "My Cool Proposal".
+2. Find the next RFC number in the sequence, say, 0284, and copy the template
+   file into `0284-My_Cool_Proposal.md`.
+3. Fill out the template as described, except for the PR link.
+4. Open a PR to add your RFC to the repo, and modify the text to include the PR
+   link (this is so that there is an easy way to find the discussion of the
+   proposal for future readers of the proposal itself).
+5. Discuss!
+
+## Accepting and implementing an RFC
+
+An RFC is accepted when its PR is approved and merged by a specification owner.
+When and whether to accept an RFC is at the owners' discretion, but will usually
+occur after some discussion of the RFC has occured on the PR.
+
+After the RFC is merged, the author may *implement* it by submitting a PR making
+text modifications to the spec(s) relevant to the RFC; in principle, the only
+thing up for discussion at this point should be the precise wording of the
+change.
+
+The current RFC owners are:
+* bryankel
+* chweimer