Skip to main content

Support Documents in IETF Working Groups
statement-iesg-support-documents-in-ietf-working-groups-20161113-00

Document Type Replaced IESG Statement
Title Support Documents in IETF Working Groups
Published 2016-11-13
Metadata last updated 2024-02-23
State Replaced
Send notices to (None)
statement-iesg-support-documents-in-ietf-working-groups-20161113-00

Support Documents in IETF Working Groups - SUPERSEDED

13 Nov 2016

There is a class of documents that help guiding a working group to agree on the problem(s) and even converge on a solution. These support documents can include, for example, problem statements, use cases, and requirements.

NOTE: This statement is superseded by the IESG Statement "Support Documents in IETF Working Groups" dated 24 August 2023

While support documents are important for the operation of a working group and to drive progress, perfecting and publishing those documents can consume scarce community resources, which in the end can delay the solution work. There is no formal expectation that requires the development and publication as RFCs of support documents in sequence before starting the solution work: problem statement, use cases, requirements, and then finally architecture and protocol specifications, for instance. 

In order to speed up the time period from idea to running code, the IESG supports working groups that commence solution work early in the working group timeline, and do not wait for completion and publication of the support documents. When the problem scope is well understood and agreed upon, charters focused on solutions work are extremely efficient. 

While writing down such things as requirements and use cases help to get a common understanding (and often common language) between participants in the working group, support documentation doesn’t always have a high archival value. Under most circumstances, the IESG encourages the community to consider alternate mechanisms for publishing this content, such as on a working group wiki, in an informational appendix of a solution document, or simply as an expired draft. As regards to timing, it would be worthwhile to discuss the need to publish support documents early during the charter development process in order to set the right expectations and minimize surprises at a late stage. Therefore, working group charters may direct the working group to publish this content using alternate mechanisms, or may instruct the working group to consider the appropriate mechanism as work proceeds.