Subject: [its] Fwd: IESG Statement: Support Documents in IETF Working Groups

From: Russ Housley <[email-masked]>
Date: Wed, 16 Nov 2016 04:02:16 -0500

During the IPWAVE WG session today, this IESG Statement was referenced.  I am posting it here to make sure that everyone understands the IESG’s position.

Russ

> From: The IESG <[email-masked]>
> Subject: IESG Statement: Support Documents in IETF Working Groups 
> Date: November 14, 2016 at 9:53:24 PM EST
> To: "IETF Announcement List" <[email-masked]>
> Reply-To: [email-masked]
> 
> 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.