Subject: IESG Statement: Support Documents in IETF Working Groups

From: The IESG <[email-masked]>
Date: Mon, 14 Nov 2016 18:53:24 -0800

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.

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.