For:

1. The RFC Editor recognizes that the needs of the technical research and engineering community and the associated documentation that describes the Internet are growing and changing.
2. The RFC Editor recognizes that other organizations offer value and may have different IPR such that working through a separate stream will allow those organizations to more effectively contribute to the workings on the Internet in a more efficient manner.
3. As the Internet evolves and changes, there is more information that should be discussed and disseminated to encourage secure, open practices; serving that purpose fits in the overall mission of the RFC Editor as described in RFC 4844.

Against:

1. There is already significant confusion regarding the categories of RFCs and how the existing streams relate to the Series. Adding a new stream would just increase the level of confusion.

1. Why the RFC Series and not a different organization or publisher? What are you hoping to achieve by publishing RFCs as opposed to self-publishing?
2. Do you anticipate your organization being a persistent entity for the next 5-10 years?
3. The RFC Series has some particular points of style and format that must be consistent across the streams. Today that means ASCII only, fixed line and page lengths, and a fairly common document structure (Abstract, Introduction, Headers, Footers, etc.) Is your organization willing to accept those constraints and participate in the discussions regarding potential changes to those constraints? Do you have any format requirements of your own, such as a UTF-8 character set or inclusion of graphics or HTML-style links?
4. How many documents do you expect to request to publish a year?

• Organization and documents must focus on improving technology or best practices for the Internet
• Open process for creation of documents
• Free
• Accept the RFC Series format and style guide
• Organization and documentation must be Community supported, not vendor driven
• Documents need to be of a quality such that the RFC Editor can edit them in a reasonable fashion (If there are enough documents that would require weeks of editing, beyond the RFC Production Center's current SLA with the IAOC.)
• A document needs to exist that specifies the stream boilerplate material (see RFC 5741 as an example), including
  • status of this memo
  • document source (e.g., stream name to be applied to the doc header)

1. What type of documents are allowed? Informational? BCP? Standards Track? etc.

1. Establish a list of questions to determine suitability (see above).
2. Require a new I-D from the supplicant describing their process, IPR policy, etc., for RSE and RSOC review.
3. Work with relevant parties to determine the terms of service and cost associated with the stream.

1. Either side may conclude the stream if funding or quality of documents runs dry

• A new stream will need to be prepared to define their processes in an RFC. Current stream documents:
  • RFC 4844 “The RFC Series and RFC Editor”
  • RFC 5743 “Definition of an Internet Research Task Force (IRTF) Document Stream”
  • RFC 5744 “Procedures for Rights Handling in the RFC Independent Submission Stream”
  • RFC 5745 “Procedures for Rights Handling in the RFC IAB Stream”

REFEDs responses