RFC 7221

RFC 7221: Handling of Internet-Drafts by IETF Working Groups 🦋

Okay bestie, this is RFC 7221 🎀 It's called Handling of Internet-Drafts by IETF Working Groups, and it came out in April 2014. A. Farrel from Juniper Networks wrote it with D. Crocker, Ed. from Brandenburg InternetWorking. It's an Informational doc, so it's published for info and isn't an Internet Standards Track spec 💅 The ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates, so no drama there 🙈

Abstract 💖

Working groups in the IETF exist to produce documents, because that's what their charter says they're supposed to do ✨ The most common move is for a group to "adopt" an existing doc and use it as the starting point. That starting doc can be anything: something already widely used, a blank sheet the group creates from scratch, or something in between. This doc walks through how a working group usually handles the formal documents it's aiming to publish 🌸

Status of This Memo 🎀

This document is not an Internet Standards Track specification. It's published for informational purposes only 💖

This is a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 🧐

For the current status, any errata, and how to send feedback, head to http://www.rfc-editor.org/info/rfc7221 🦋

Copyright Notice 🌸

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved 💜

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info, as they stood on the date this was published. Please actually read those, bestie, because they spell out your rights and restrictions for this document. Any Code Components pulled out of this document have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They also come with no warranty, as described in the Simplified BSD License itself ⚖️

Table of Contents 🧚

1. Introduction ....................................................2
   1.1. What Is a WG Draft? ........................................3
   1.2. Working Group Authority and Consensus ......................4
   1.3. Questions Considered in This Document ......................5
2. Adoption Sequence ...............................................6
   2.1. Common Steps ...............................................6
   2.2. Criteria for Adoption ......................................6
3. Authors/Editors .................................................8
4. Document History and Stability ..................................8
5. Some Issues for Consideration ..................................10
   5.1. Individual I-Ds under WG Care .............................10
   5.2. WG Drafts Can Become Individual Drafts ....................11
   5.3. Competing Drafts ..........................................11
6. Security Considerations ........................................13
7. Acknowledgements ...............................................13
8. Informative References .........................................13

1. Introduction ✨

The whole point of an IETF working group (WG) is to make documents, as set out in its charter 📄 Working groups build these docs from initial input at all kinds of maturity levels. A starting draft could be something already in wide use, a blank page the group writes itself, or anything in between 🍓

This document is about how a WG usually handles the formal docs it's targeting for publication. It only covers the IETF, not IRTF groups, because their practices vary a lot 🌈

Inside the general rules of formal IETF process and the specific limits of a group's charter, there's actually a lot of freedom in how drafts get adopted and developed 🦋 The final call on those choices is always working group agreement, still within the charter. That agreement could be spoken out loud or just implied, depending on what efficiencies the group thinks make sense 💅

NOTE: This document is intentionally non-normative. It's meant as a guide to common practice, not as a formal definition of what's allowed.

1.1. What Is a WG Draft? 🎀

Working group drafts are docs under WG revision control. Getting one published as an RFC needs rough consensus in the working group first, then in the wider IETF 🫶 Creating or adopting a draft as a group, and making big changes to it, both need to represent working group rough consensus too ✨

Docs being developed in the IETF community get shared as Internet-Drafts (I-Ds) [RFC2026] [ID-Info]. Working groups use this system for their official output, per Section 7.2 of [RFC2418] and Section 6.3 of [Tao]. To show an I-D is formally owned by a working group, the filename puts "ietf" in the second field and the working group name in the third field, per Section 7 of [ID-Guidelines]. It looks like this 👑

draft-ietf-<wgname>-...

Individual submissions are the opposite: drafts being made and pursued outside any working group. A WG might still adopt one later, which we'll get to. Anyone can create an individual submission at any time 🧚 These usually get named after the author or editor's last name, like this:

draft-<lastname>-...

(Also see Section 5.1 for more on this naming 💜)

The direct revising of a WG I-D belongs to its editors and authors. Section 3 has the details on how they get picked and what they do 🌸

1.2. Working Group Authority and Consensus 💖

The IETF runs on a simple idea: inside a working group, the group itself has the final say over what goes in its documents, as long as it sticks to the charter. No single person gets special authority over content 🙅‍♀️ The Chairs can assign document authors and editors and set up design teams, but in the end, WG docs always need working group approval. That approval runs on the IETF's "rough consensus" idea, which is basically the IETF choosing practical results over fussy niceties 🔥 Unanimous agreement is always the dream, but rough agreement is good enough as long as it's clear and strong 💅

Apart from picking authors and editors (see Section 3), a working group's decisions about managing its documents follow the normal IETF rough consensus rules. Section 3.3 of [RFC2418] and Section 4.2 of [Tao] describe how this works for a WG, and [Consensus] digs into what rough consensus actually means 🦋

The working group openly builds, changes, reviews, and approves document content through formal rough consensus. For tough topics or messy group dynamics, that slow process is really necessary, because it checks progress at every step 🫶 Simpler stuff often gets a faster route, though, like a Chair stating the likely agreement and just asking if anyone objects 🌈 Ultimately, how a working group decides things depends on how comfortable and engaged the group feels with the method it's using ✨

Sometimes an author or editor looks like they're calling all the shots on content, but that's only for efficiency 🎀 Chairs can let authors and editors move forward on an implied, default working group agreement, as long as the group is cool with that approach. The upside is speed, but the risk is that the group never actually confirms the consensus it has 🙈 When the author or editor is driving content directly, an easy check is for the Chairs to ask the working group for comments and concerns every time a new version shows up 💜

If it isn't obvious what the working group thinks, the Working Group Chairs can poll the group to find out 🧐 The way you ask the question matters. A plain "yes/no" question usually isn't that helpful. It works better to ask supporters and detractors of a draft (or the decision on the table) to explain their reasons, not just their preferences 💅 That way consensus becomes an ongoing conversation, and ideally the discussion changes the document, the participants' views, or both 🦋

1.3. Questions Considered in This Document 🧚

This doc is all about the criteria and steps usually followed when a formal IETF working group document gets adopted and developed. It's especially aimed at Working Group Chairs who are running that process, so it covers these questions 👑

• 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. Adoption Sequence 🌈

2.1. Common Steps 🍓

When people want a document adopted as a new working group document, the Chairs often do the following, in roughly this order 💖

1. Remind the current draft owners that they're handing over change control of the document to the IETF. (This matters a lot for documents covered by proprietary interests, since it usually means negotiating between the current owners and the IETF, including a formal agreement 😭)
2. Check for known IPR that needs to be disclosed, using some technique like those described in [RFC6702] 🔍
3. Get working group rough consensus 🫶
4. Choose the document editors ✨
5. Tell the authors to post the WG I-D 📝
6. Approve the posting [Approval] ✅
7. Make sure 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.2. Criteria for Adoption ✨

okay so there's no formal spec for working group "adoption" 🙈 this doc is just meant to describe the usual activities, but ngl it's not normative, so don't treat it like a rulebook. 📋

when a working group is deciding whether to adopt a draft, these are the basic things to think about:

• 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? 🌸
• Is the purpose of the draft sufficiently clear? 🔍
• Does the document provide an acceptable platform for continued effort by the working group? 🏗️
• 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? 🧐
• If not already in scope, is a simple modification to the charter feasible and warranted? 🛠️
• Does the draft carry known intellectual property rights issues? ⚖️
• Is there strong working group support for working on the draft? 🫶

adoption also comes with some basic pragmatics, and these are lowkey the best part 💅

• Rough consensus: working group agreement to adopt is not required to be unanimous [RFC2418]. no one has to be 100% on board, bestie 🤝
• Initial, not final: the writing quality is not required to be "ready for publication". writing quality can still be a problem and does need explicit attention. although it's 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. being adopted is not the same as being published, periodt 🌷
• Group, not Chairs: concerning the draft, the position of the Working Group Chairs has no special authority, except to assess working group consensus. the chairs read the room, they don't own the vibe 👑

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. 🚩

---

3. Authors/Editors ✨

okay the Working Group Chairs are the ones who pick the document authors and editors 🎀 editors are described in Section 6.3 of [RFC2418], and authors and editors are described in [RFC-Auth-Ed]. go read those if you're curious 📚

NOTE: in this document, the terms 'author' and 'editor' are meant interchangeably. within the IETF, the distinction between an 'author' and an 'editor' is, at best, subjective. a simplistic rule of thumb is that editors tend to do the mechanics of incorporating working group detail, whereas authors tend to create the detail, subject to working group approval. that is, one role is more active with the content, and the other is more passive. it is a responsibility of the Working Group Chairs to ensure that document authors make modifications in accord with working group rough consensus. authors/editors are solely chosen by the Chairs -- although the views of the working group should be considered -- and are subject to replacement for a variety of reasons, as the Chairs see fit. 💜

for existing documents that are being adopted by a working group, picking editors gets a little tricky 🙈 the document already had editors, so the question "are the same people appropriate for continuing the task?" comes up. sometimes the answer is yes, but it's not automatic. the process inside an IETF working group can be quite different from the process that created previous versions, so it might make sense to pick one or more new editors. they could be added to the editor team, or become the primary pen-holders (which effectively reclassifies the previous team as coauthors) 🦋

if the original editors are staying on, the Chairs might want to make sure they understand IETF working group process, because it's likely to be quite different from the process that developed earlier versions of the document. if new or additional editors get assigned, the transition can be discussed, including its reasons. this is best done as soon as possible, so nobody is caught off guard 🫶

---

4. Document History and Stability ✨

working group charters sometimes name an initial set of existing documents to use as a basis for the group's work. that 'basis' can vary a lot, from simple input to working group discussion all the way to an advanced draft that's been adopted by the group and is only getting minimal changes. the role of a document should be explicitly stated in the charter, no vague vibes allowed 📜

within the scope of its charter, a working group is free to create new documents 🌈 it's not required that every draft starts as one individual's effort. of course, the criteria for brand new documents are likely to be the same as for those imported into the working group. the one extra, obvious requirement is that the Working Group Chairs will need to appoint authors/editors before any work can progress. also, from time to time, a working group will form a design team to produce the first version of a working group draft. design teams are discussed in Section 6.5 of [RFC2418]. 🧚

work that gets brought to the IETF has different levels of completeness and maturity, and different timings for reaching those levels. when the IETF charters a group and includes existing material, the charter can cast the role of that material in very different ways. it can treat it as:

• no more than a set of ideas, to be used or ignored; 💭
• a basic design, with all of the actual details still fluid; 🌊
• a rough draft, subject to extensive revision; ✏️
• a solid specification that merely needs review, refinement, and maybe enhancement; 💎
• a deployed technology that is best served by trying to protect its installed base, but with some tolerance for changes that affect interoperability; 🏠
• a deployed technology for which protecting the installed base is essential, including retention of core interoperability. 🛡️

these suggest a wide range of possible constraints on working group effort. technology shows up at the IETF at different points along its life cycle, and the nature of the technology can have very different utility in developing an Internet standard. it's a whole spectrum, babe 🌸

when technology is brand new, with at most some prototypes done as proofs of concept, significant changes to the specification will not necessarily add much to the development and deployment costs. however, when the technology is already part of a mature and extensive operational deployment, any changes that are incompatible are likely to be problematic for that market and can hinder adoption of the changes overall. for example, immediately after the development investment is made -- and especially when there has been considerable initial deployment but there is still room for quite a bit more -- the installed and potential base might not take kindly to disruptive standards work that undermines their recent investment. 😬

conversely, even a deployed technology with a solid base might be inappropriate to deploy at Internet scale. while a document specifying such a technology might serve as a good starting point for a new specification, undermining the deployed base might be completely appropriate. plot twist 🎭

in reflecting upon the basis for adopting an existing draft, and the way it will be used by the working group, it is important to consider the document's place in its life cycle, the needs of any installed base, and the applicability of the draft's technology. all of that matters when deciding on the constraints to impose on document development. it will all depend on the constraints of the charter and the analysis of the working group. ✨🧠

---

5. Some Issues for Consideration ✨

5.1. Individual I-Ds under WG Care 🧑‍💻

sometimes a working group facilitates a draft but doesn't 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 that's formally under the ownership of a working group is to follow this 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 below, where the second element is the last name of one of the principal authors.

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

having the working group name after the personal name lets tools associate these drafts with the working group, even though the filename identifies them as the work of individuals. smart, right? 🧚

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, the working group, and the 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. WG Drafts Can Become Individual Drafts 🌷

a working group is not obligated to keep documents it has adopted. sometimes working group efforts conclude that a draft is no longer appropriate for working group effort. if a working group drops a draft, then anyone is permitted to pursue it as an Individual or Independent Submission, subject to the document's existing copyright constraints. it's not a breakup, it's just a glow-up on their own 💅🦋

5.3. Competing Drafts 🔥

Okay so engineering for interesting topics almost always produces competing, interesting proposals 💅 The reasons can be technical aesthetics, engineering trade-offs, architectural differences, company economics, and the like. Ngl it's way more comfy to entertain only one proposal, but a working group is free to pursue more than one. Often this is necessary until a clear preference develops 🌸 Sometimes multiple versions get formally published even though the alternatives don't have consensus yet ✨

It's super appealing to ask the 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 merge discussions are often better held in a design team than amidst the chaos 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 just can't be resolved, and trying to merge them can produce a weaker result 💀 An example of this conflicting design goals problem is discussed in [Heli-Sub], which says:

"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 help with handling 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 shows up 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?

---

6. Security Considerations 🚨

Gasp, the security section! 😱 Beyond the credibility of the IETF, this document raises no security concerns. That's the whole tea, bestie 🍵

7. Acknowledgements 🎀

This document was developed from an IETF tutorial given by A. Farrel at an IETF Working Group Chairs lunch [Farrel-Chairs]. L. Anderson contributed useful comments 🫶

8. Informative References 📚

[Approval] IETF, "IETF Internet-Draft Initial Version Approval Tracker", (IETF Datatracker), <https://datatracker.ietf.org/cgi-bin/wg/wg_init_rev_approval.cgi>.

[Consensus] Resnick, P., "On Consensus and Humming in the IETF", Work in Progress, April 2014.

[Farrel-Chairs] Farrel, A., "What is a Working Group ID (and when to adopt one)", (IETF 78 WG chairs lunch Material), July 2010, <http://wiki.tools.ietf.org/group/edu/wiki/IETF78#>.

[Heli-Sub] Rose, M., "On Helicopters and Submarines", ACM Queue - Instant Messaging, Vol. 1, Issue 8, Page 10, <http://dl.acm.org/ft_gateway.cfm?id=966726>.

[ID-Guidelines] Housley, R., Ed., "Guidelines to Authors of Internet-Drafts", December 2010, <http://www.ietf.org/ietf-ftp/1id-guidelines.txt>.

[ID-Info] Wijnen, B., Ed., "Checklist for Internet-Drafts (IDs) submitted for RFC publication", May 2009, <https://www.ietf.org/id-info/checklist.html>.

[IDNITS] IETF, "IDNITS Tool", 2013, <https://tools.ietf.org/tools/idnits/>.

[Individual] IESG, "Guidance on Area Director Sponsoring of Documents", March 2007, <http://www.ietf.org/iesg/statement/ad-sponsoring-docs.html>.

[RFC-Auth-Ed] RFC Editor, "RFC Editorial Guidelines and Procedures -- Author Overload", 2014, <http://www.rfc-editor.org/policy.html#policy.authlist>.

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.

[RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998.

[RFC6702] Polk, T. and P. Saint-Andre, "Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules", RFC 6702, August 2012.

[Tao] Hoffman, P., Ed., "The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force", 2012, <http://www.ietf.org/tao.html>.

---

Authors' Addresses 💌

Adrian Farrel
Juniper Networks

EMail: adrian@olddog.co.uk


Dave Crocker (editor)
Brandenburg InternetWorking
675 Spruce Drive
Sunnyvale, CA  94086
USA

Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net