RFC Submission

Prior to embarking on new features or large functional changes to a project, often an RFC will be submitted to get feedback on the proposed effort. This is a very standard practice and we would like to encourage its use on the OpenXT project as well. To begin with, there is the standard RFC layout that has been around for years. E.g. this IETF one for HTTP 1.1:

https://www.ietf.org/rfc/rfc2616.txt

This RFC about RFC's is also helpful:

http://tools.ietf.org/html/rfc2119

And some more RFC guidelines:

https://www.rfc-editor.org/policy.html

In general, following the IETF RFC format to a greater or lesser degree is a reasonable choice.

Best Practices

The OpenXT organization would like to make some suggestions as to what the community believes would be best practices in format and content for submitting RFC's. First though, realize that the OpenXT community welcomes all contributions to the organization. So if someone has good reason to make a submission using their own format/content/etc, they should do so. An example is a contributor that has an existing specification with many diagrams embedded in it that fully describes their system and wants to add it to their RFC (perhaps as an attachment). The downside to this is that other formats require reviewers to use other tools and it is not as easy (or even possible) to comment inline within the RFC.

The preferred format for RFC submission is plain text directly inline in a post on the mailing list (Google Group). This allows easy viewing without special tools. It also allows simple inline comments and suggestions to be posted back to the list.

The RFC should contain the following elements:

• Title: The RFC should include a succinct single line title that indicates what the RFC is; this should also be part of the subject for the posting.
• Date: The RFC should include the month and year for the submission.
• Abstract Section: The RFC should provide a concise and comprehensive overview of the purpose and contents of the entire document.
• Body Section: The RFC should have a body where the bulk of the information resides.

Some other elements an author may or may not want to include:

• Copyrights: The RFC can include multiple copyright lines.
• Authors: The RFC can include author's names, emails and contact information.

A few other things to keep in mind:

• The abstract section should clearly indicate why the submission is being done, what problem the proposal is solving and why it benefits the OpenXT organization.
• If the body section is very large, the author should consider using a TOC or some other means to organize the text. This will also make it easier to reference specific items by a number or tag.

Example:

RFC for Paravirtual Framus Driver Support

November 2014

Abstract:

This document specifies a proposal to add new PV Framus drivers
to provide virtual Framus support for guests in OpenXT. Framus
hardware has become ubiquitous on most PC hardware and providing
virtual Framus support to guests is vital to any virtualization
platform including OpenXT. The remainder of this document will
outline exactly how Framus virtualization can be achieved using
...etc...etc

Body:

Etc...etc...etc...