Handling and Adoption of Internet-Drafts by IETF Working Groups

1.1. What Is a WG Draft?

Working group drafts are documents that are subject to IETF working group revision control, with advancement for publication as an RFC requiring rough consensus in the working group and then in the broader IETF. Creation or adoption of a draft by a working group -- as well as substantive changes to the document -- need to represent working group rough consensus.¶

Documents under development in the IETF community are distributed as Internet-Drafts (I-Ds) [RFC2026] [ID-Info]. Working groups use this mechanism for producing their official output, per Section 7.2 of [RFC2418] and Section 6.3 of [Tao]. The common convention for identifying an I-D formally under the ownership of a working group is by the inclusion of "ietf" in the second field of the I-D filename and the working group name in the third field, per Section 7 of [ID-Guidelines]. That is:¶

                   draft-ietf-<wgname>-...

In contrast, individual submissions are drafts being created and pursued outside of a working group, although a working group might choose to adopt the draft later, as discussed below. Anyone is free to create an individual submission at any time. Such documents are typically distinguished through the use of the author/editor's last name, in the style of:¶

                    draft-<lastname>-...

(Also see Section 5.1 for an elaboration on this naming.)¶

Responsibility for direct revision of a working group I-D is assigned to its editors and authors. See Section 3 for discussion about their selection and role.¶

1.2. Working Group Authority and Consensus

A premise of the IETF is that, within a working group, it is the working group itself that has final authority over the content of its documents, within the constraints of the working group's charter. No individual has special authority for the content. The Chairs assign document authors/editors and can formulate design teams, but the content of working group documents is always, ultimately, subject to working group approval. Approval is described in terms of the IETF's "rough consensus" construct, which is the prime example of the IETF's preference for pragmatics over niceties. Unanimous agreement is always desirable, but more approximate (rough) agreement will suffice, as long as it is clear and strong.¶

Other than for selection of document authors/editors, as discussed in Section 3, working group decision-making about document management is subject to normal IETF rough consensus rules. Useful descriptions of this process for a working group are in Section 3.3 of [RFC2418] and Section 4.2 of [Tao]. Discussion of the nature of rough consensus can be found in [RFC7282].¶

In terms of the IETF's formal rough consensus processes, the working group explicitly develops, modifies, reviews, and approves document content, according to overt rough consensus. For difficult topics and/or difficult working group dynamics, this laborious process really is essential. Its diligence validates progress at each step along the way. However, working groups often handle simpler matters more simply, such as allowing a Chair to assert the likely agreement and then merely call for objections. Ultimately, the mode of working group decision-making is determined by the comfort and engagement of the working group with the way the decisions are being made.¶

At times, a document author/editor can appear to have considerable authority over content, but this is (merely) for efficiency. That is, the Chairs can permit authors and editors to proceed with an implied (default) working group agreement, as long as the working group is comfortable with that mode. Of course, the benefit in the mode is efficiency, but its risk is failure to retain or verify actual consensus among the working group participants. When a working group is operating in the mode of active, direct author/ editor content development, an easy validation method is simply to have Chairs query the working group when a new document version appears, asking for comments and concerns.¶

In general, when it is not completely obvious what the opinion of the working group is, Working Group Chairs can poll the working group to find out. As with any other consensus question, the form in which it is asked can make a difference. In particular, a general 'yes/no' question often is not as helpful as asking supporters and detractors of a draft -- or of the decision under consideration -- to provide their reasons, not merely their preferences. In effect, this treats the matter of consensus as an ongoing discussion. Ideally, the discussion can produce changes in the document or in participant views, or both.¶

1.3. Questions Considered in This Document

The purpose of this document is to discuss the criteria and sequence typically followed when adopting and developing a formal IETF working group document. Therefore, this document considers the following questions that are particularly relevant to Working Group Chairs who are charged with running the process:¶

• How do Working Group Chairs decide which drafts to adopt and when?¶
• Is it necessary to poll the working group explicitly, and what does a working group poll look like?¶
• How do Working Group Chairs make the decision?¶
• What are the process steps the working group will choose to use, for an I-D to become a WG I-D?¶
• Are there any special cases?¶
• Can a document be created as a WG I-D from scratch?¶
• How can competing drafts be handled?¶
• Can an individual I-D be under the care of a WG?¶
• Can a WG I-D become an individual I-D?¶

2.1. Consequences of WG Adoption of an Internet-Draft

After a draft has been formally adopted by a WG, its original authors no longer have formal change control of the text. In addition to the normal consequence of posting a draft, i.e., that it becomes an IETF Contribution under [RFC5378], all future substantive changes to the draft require WG consensus and are no longer at the authors' sole discretion.¶

As a practical matter, the original authors usually continue to edit the document and make routine editorial decisions, but substantive changes must be referred to the WG and require WG rough consensus, consistently with [RFC2418]. It is also possible that new authors or editors will join the draft, or that previous authors may withdraw.¶

Adoption represents a commitment that the WG will spend time and effort on the draft, but it does not guarantee that the draft will reach WG consensus and be submitted to the IESG for publication as an RFC.¶

2.2. Relationship to Formal IETF Rules

A WG Adoption Call of an I-D is not a required step of the IETF standards process. The WG chairs decide what documents belong in the WG, and can create new documents by fiat. A simple situation would be if a WG decides that an existing document should be split into two pieces: there is no reason to adopt each piece, that is needless bureaucracy. Similarly, if there is WG consensus to merge two drafts into one, a complete adoption procedure may be pointless. However, a WG that decides to create a design team to solve a problem has not agreed to adopt the result automatically. The design team's output has the same status as any other draft, even if it has a high chance of being adopted.¶

It is legitimate for a draft to be submitted to the IESG as described in [RFC2026] without a formal adoption by a WG. Clearly this should only happen when the WG Chairs are already satisfied that there is strong consensus to do so.¶

2.3. Common Steps

Any participant may request the adoption of a draft, after there has been a period of technical discussion of the draft in the relevant WG.¶

WG Chairs have discretion about when to issue a call for adoption, but they should do so regardless of their own opinions, when the WG discussion shows that there is clear interest in the draft in question.¶

When there is interest in adopting a document as a new working group document, the Chairs (or a WG Secretary, if there is one) typically:¶

1. Remind current draft authors that they are transferring change control for the document to the IETF. (This is a particularly significant point for a document covered by proprietary interests, because it typically entails a negotiation between the current owners and the IETF, including a formal agreement.)¶
2. Check for known IPR that needs to be disclosed under [RFC8179], using some technique like those described in [RFC6702]. This might be combined with the following action.¶

3. Obtain working group rough consensus. Typically the Chairs or WG Secretary will send a call for adoption of a draft to the WG mailing list with at least two weeks time to respond.¶

   • After this period, a WG Chair should, in a timely fashion, consider the comments and discussion in order to judge whether there is rough consensus to adopt the draft, and whether there is enough interest in the work that its completion is likely. The result should be announced to the WG.¶
4. Choose document editors. As noted above, these might or might not be the existing authors.¶
5. Request authors to post the WG I-D according to the naming convention described above.¶
6. Approve posting [Approval].¶
7. Ensure that the non-working group version of the draft is marked as being replaced by this working group version.¶
8. Encourage everyone to enjoy the ensuing working group discussion...¶

2.4. Criteria for Adoption

No formal specification for working group 'adoption' of a draft exists; the current document is meant to provide a description of common activities for this, but again note that it is not normative. Participants responding to a WG call for adoption should consider these points.¶

There are some basic considerations when deciding to adopt a draft:¶

• Is there a charter milestone that explicitly calls for such a document?¶
• Is the topic of the I-D within scope for the working group?¶
• If not already in scope, is a simple modification to the charter feasible and warranted?¶
• Is the purpose of the draft sufficiently clear?¶
• Is the proposal useful?¶
• Does the document provide an acceptable platform for continued effort by the working group? In particular, is the quality of writing sufficient to serve as the basis further work?¶
• What are the process or technical objections to adoption of the draft?¶
• Is the draft likely to be completed in a timely manner?¶
• Does the intended status of the document seem reasonable to the working group?¶
• Does the draft carry known intellectual property rights issues? If so, are the IPR disclosures acceptable?¶
• Is the work in conflict with work elsewhere in the IETF?¶
• Is there strong working group support for working on the draft?¶

An informal summary of these questions is: Is this a problem the WG wants to solve in a way approximately as described in the draft?¶

Adoption has some basic pragmatics:¶

Rough consensus:

Working group agreement to adopt is not required to be unanimous [RFC2418].¶

Initial, not final:

The writing quality is not required to be "ready for publication", although writing quality can be a problem and does need explicit attention; although not mandatory, it is good practice to check whether a new working group draft passes [IDNITS].¶

Adoption, not approval:

The document is not required to already contain a complete and/or sufficient solution, although of course this can be helpful. Equally, adoption by a working group does not guarantee publication of the document as an RFC.¶

Group, not Chairs:

Concerning the draft, the position of the Working Group Chairs has no special authority, except to assess working group consensus.¶

REMINDER:

Once a working group adopts a draft, the document is owned by the working group and can be changed however the working group decides, within the bounds of IETF process and the working group charter. Absent explicit agreement, adopting a document does not automatically mean that the working group has agreed to all of its content. So a working group (or its charter) might explicitly dictate the basis for retaining, removing, or modifying some or all of a draft's content, technical details, or the like. However, in the absence of such constraints, it is worth having the adoption process include a sub-process of gathering working group concerns about the existing draft and flagging them explicitly.¶

5.1. Individual I-Ds under WG Care

Sometimes, a working group facilitates a draft but does not own it or formally adopt it. These are "individual" drafts [Individual].¶

As noted in Section 1.1 and reinforced in [ID-Guidelines], the convention for identifying an I-D formally under the ownership of a working group is by following the naming convention:¶

               draft-ietf-<wgname>-...

By contrast, documents that are still under the control of their authors are known as "individual" I-Ds. When these documents are intended for consideration by a specific working group, the convention is that the document uses the naming convention as follows, where the second element is the last name of one of the principal authors.¶

            draft-<lastname>-<wgname>...

Having the working group name following the personal name allows tools to associate these drafts with the working group, even though the filename identifies them as the work of individuals.¶

The working group can choose to apply any of its normal, internal working group process management mechanisms to an individual I-D. However, matters of ownership, working group final approval, and the like are all subject to negotiation amongst the document authors, working group, and Area Directors.¶

This is a rare situation, and Working Group Chairs can be assured that the Area Directors will want to understand why the document could not be adopted and owned by the working group.¶

5.2. Withdrawal of an Adopted Internet-Draft

It sometimes happens that an adopted draft does not reach WG consensus to be submitted to the IESG for publication as an RFC due to lack of interest, lack of effort, or lack of agreement. In such a case, it may be desirable for the WG to formally withdraw the WG draft, such that it is explicitly removed from the WG's agenda. If a working group drops a draft, then anyone (most likely the original authors) can pursue it as an Individual or Independent Submission, subject to the document's existing copyright constraints.¶

The withdrawal of a WG document should be the result of an explicit decision by the relevant WG, and the Chairs should consider the following recommendations.¶

• Upon evidence that progress on a WG draft has been stalled for a considerable period of time, a WG chair should evaluate the reasons of the apparent lack of progress. Such reasons may may include lack of interest, lack of effort, or lack of consensus.¶
• When progress on a document has been stalled for a considerable period of time, a WG chair, in consultation with the WG draft authors and editors, should attempt to resume progress by taking appropriate actions that will normally depend on the nature of the lack of progress. For example, a WG draft that has been stalled due to apparent lack of interest may benefit from a call for a number of volunters to produce detailed reviews of the WG draft. Similarly, a WG draft that has been stalled due to lack of effort by its authors/editors may benefit from the incorporation of new WG draft editors or the replacement of some of the existing ones.¶
• If after succesive failed attempts to make progress on a WG draft its completion remains unlikely, the WG Chairs may, at their own discretion, conclude that it is time for the WG to consider the formal withdrawal of the WG draft.¶
• In such case, a WG Chair or WG Secretary would send a formal WG consensus call for withdrawal of the WG draft to the WG mailing list with at least two weeks time to respond, explaining the events that have triggered the aforementioned consensus call.¶
• After this period, a WG Chair should, in a timely fashion, consider the comments and discussion in order to judge whether there is any concrete evidence that completion of the work may now be feasible, or whether completion of the work remains unlikely.¶
• If further progress on the document remains unlikely, the WG Chair will announce the result of the consensus call and the formal withdrawal of the WG document. This will result in the document being removed from the WG's agenda and returned to the authors' control.¶

5.3. Competing Drafts

Engineering for interesting topics often produces competing, interesting proposals. The reasons can be technical aesthetics, engineering trade-offs, architectural differences, company economics, and the like. Although it is far more comfortable to entertain only one proposal, a working group is free to pursue more than one. Often this is necessary until a clear preference develops. Sometimes, multiple versions are formally published, absent consensus among the alternatives.¶

It is appealing to ask authors of competing proposals to find a way to merge their work. Where it makes sense to do this, it can produce a single, strong specification. The detailed discussions to merge are often better held in a design team than amidst the dynamics of an open working group mailing list. The working group has ultimate authority over any decisions, but it is not required that it be involved in all the discussions.¶

On the other hand, some differences cannot be resolved, and attempting a merge can produce a weaker result. An example of this problem of conflicting design goals is discussed in [Heli-Sub], noting:¶

    "Helicopters are great, and so are submarines.  The problem is
    that if you try to build one vehicle to perform two fundamentally
    different jobs, you're going to get a vehicle that does neither
    job well."

Various management efforts can facilitate the handling of competing proposals. Some examples include:¶

• Developing a requirements document that is independent of specific proposals; this can highlight features that are deemed essential and distinguish them from features that are of secondary importance, and can facilitate a discussion about features without reference to specific proposals.¶
• Developing a comparison table of the proposals; this can aid understanding of their differences.¶
• Discussing the relative importance and effects of having one proposal, versus multiple; this can focus people's efforts at compromise and encourage a willingness to choose a single proposal.¶

The problem of competing drafts can be particularly painful when it arises in either of two circumstances:¶

• If a second proposal appears as a new draft, just as the Chairs were ready to poll the working group on adoption of the draft containing the first proposal, then the authors of the first proposal could feel affronted. It does not follow that the second draft was written to be difficult or derail the first: it might even include better ideas. So it is best not to disregard it. However, automatically asking the authors to merge their work will not necessarily produce a more solid solution and will not guarantee faster progress. This situation will be a judgement call in each case, and it might help to ask the working group for their opinion: shall the working group adopt one document as a starting point and fold in the ideas from the second under the control of consensus, or shall the working group wait until the authors of both documents have reached agreement?¶
• If the working group has already adopted an I-D on a specific topic, the posting of a new individual I-D on the same topic could be seen as an attack on the working group processes or decisions. However, posting an I-D is often a good way to put new ideas into concrete form, for public consideration and discussion. The Working Group Chairs will want to encourage the working group to consider the new proposal. Shall it be adopted and entirely replace the current working group draft? Shall the new ideas be incorporated into the work of the working group through the normal editorial process? Shall the working group adopt a second competing solution? Or shall the new draft be rejected and not adopted by the working group?¶