Summary

  • draft-ietf-procon-2418bis-04, posted on 17 August 2026, adds an explicit sentence saying that a working group can return an Internet-Draft to a non-adopted state, for example when interest wanes. Revision -03 did not contain that exit sentence.
  • The text is a current WG Document with IESG state I-D Exists, not approved IETF policy. It matters because it describes adoption as reversible custody of a work item rather than permanent approval of a proposal.
  • Earlier IETF guidance already says adoption is initial rather than final, does not approve every part of a draft and does not guarantee an RFC. It also says a working group need not retain an adopted draft, while the document-state model distinguishes active, parked and dead work.
  • A trustworthy reversion needs a disposition receipt: the adoption and reversion decisions, last WG-owned revision, reasons, resulting state, editor and change-control handoff, successor links, unresolved issues and known external reliance. Non-adopted must not be expanded into technical rejection, RFC withdrawal, expiry or operational shutdown without separate evidence.

The sentence that creates an exit

The news is one sentence in a document about documents.

Section 8.2 of revision -04 says a working group may formally adopt an Internet-Draft as the basis for one of its work items. It immediately limits the meaning of that act: adoption does not indicate that the draft’s contents have consensus. Editors are then charged with documenting the outcomes of the group’s deliberations. The paragraph ends by saying that working groups may also return Internet-Drafts to a non-adopted state, with waning interest given as an example.

The last sentence did not appear in revision -03. That version already separated adoption from agreement with everything in the draft, but it stopped after assigning editors the task of recording consensus. The -04 change log records another modification to the adoption text. The change is therefore not an inference drawn from a generic process update; it is visible in the successive manuscripts.

This is modest language. It does not define a mandatory notice period, a vote threshold, a new appeal, or a universal taxonomy for what happens next. Waning interest is an example, not a metric. No named working group is accused here of having mishandled a draft. Yet the sentence closes a conceptual gap. If a group can take a document into collective custody, it needs a legible way to end that custody without pretending the earlier adoption never happened.

That matters outside meeting minutes. Product teams use working-group status to decide what to prototype. Other standards authors build references and dependencies around active documents. Lawyers and procurement teams sometimes treat the draft-ietf name as stronger evidence of institutional support than it is. A reversible state tells all of them that the work item has a history, a current owner and a possible end—three different facts, not one badge.

A current draft, not a new rule

The status boundary is essential because the document seeks to rewrite an important governance baseline.

The PROCON document page lists draft-ietf-procon-2418bis-04 as a new WG Document dated 17 August 2026. Its individual Datatracker record gives it an intended status of Best Current Practice and says it would obsolete RFC 2418 and RFC 3934 and update several later RFCs if approved. As of 27 August, however, the IESG state was only I-D Exists. There was no document shepherd, responsible Area Director or telechat date, and the draft was due to expire on 18 February 2027 unless updated or advanced.

The neighbouring 2026bis draft was in Working Group Last Call. 2418bis was not. Conflating the two would turn a list layout into a false decision.

The PROCON charter does give the group authority to do this work. Its core mission is to consolidate the many RFCs that update the IETF’s standards-process and working-group guidelines. It also specifically permits non-editorial revision of guidelines for working-group adoption. Charter scope explains why the sentence is in bounds. It does not approve the sentence.

Until the Internet-Draft completes the applicable IETF process, RFC 2418 remains part of the published BCP 25 baseline. A policy inventory should therefore store two simultaneous truths: current published rule and proposed replacement text. Calling -04 merely a suggestion loses its institutional context; calling it the new IETF rule invents an outcome.

Adoption transfers custody, not truth

The proposed exit makes sense only after adoption is classified correctly.

RFC 7221, an informational account of common IETF practice, describes the typical adoption sequence. Draft owners are reminded that change control transfers to the IETF. Chairs check intellectual-property disclosures, obtain working-group rough consensus, select editors, arrange the draft-ietf version and preserve replacement information. The criterion is whether the document offers an acceptable platform for continued effort.

That is a choice of working material. RFC 7221 labels adoption “initial, not final” and “adoption, not approval.” The draft need not contain a complete solution, and adoption does not guarantee publication as an RFC. Once adopted, the document belongs to the working group and can be changed as the group decides within its charter and IETF process. Unless the group says otherwise, adoption does not mean agreement with all existing content.

There are two controls in that description. The working group, not the original authors, gains authority over the document’s development. But the working group gains authority to deliberate and revise, not an obligation to ratify the starting text. Editors hold the pen to record the group’s outcomes; they do not inherit a private mandate to define those outcomes.

This is why “endorsement” is a dangerous database synonym for adoption. Endorsement sounds like a durable evaluation of the technical object. Adoption is closer to accepting a case onto a collective docket. It commits scarce attention, creates expectations and transfers document control. It can be an important signal of interest without being a certificate of correctness.

The reverse transition should be read at the same level. Returning the draft to non-adopted status ends or changes the working group’s custodial commitment. It does not logically negate every reason that once supported adoption, and it does not answer every technical question that arose after it.

The old state machine already had side doors

The -04 sentence is new in the proposed successor text, but reversibility is not alien to the IETF’s documentary record.

RFC 6174 defines a working-group document-state model. A call for adoption means the draft is under consideration and has not yet achieved selection. If it is not adopted, it returns to no stream-specific state, while the history still records that the call occurred. Adopted by a WG captures the interval before an author posts the new draft-ietf version. WG Document means an adopted draft under active development.

The model then supplies side states. A Parked WG Document may lack an editor, await another document or review, or be unable to progress for another reason. An annotation can explain what would unpark it. A Dead WG Document is abandoned, but even “Dead” is not necessarily final: the draft can be resurrected, or a non-expired document can move to another group with the required consent. The state diagram also says that the absence of a drawn arrow does not prohibit an appropriate transition.

These distinctions are operationally useful because they answer different questions:

  • WG Document says the group owns and actively develops the work.
  • Parked says custody continues while progress has stopped for an identified reason.
  • Dead says the WG effort has been abandoned, while retaining history and possible later movement.
  • Non-adopted says the document is no longer the basis of a WG work item; the next ownership and stream state must be recorded rather than guessed.
  • Expired says the repository lifetime elapsed; it does not itself supply a collective disposition.

The vocabulary is not perfectly unified across documents, and 2418bis-04 does not yet say exactly how its phrase would map to every Datatracker state. That is a real open implementation question. It is also the reason not to collapse the words now. A useful state model preserves differences until the responsible institution defines the mapping.

RFC 7221 supplies the substantive escape route. A working group is not obliged to retain a document it adopted. If the group drops it, anyone may pursue the work as an Individual or Independent Submission, subject to the document’s copyright constraints. Ending WG ownership is therefore not necessarily deletion of the proposal. It can be a change of venue and authority.

Non-adopted is not a verdict

Suppose interest wanes. That observation can describe several different realities.

The problem may no longer be urgent. The group may lack editors or reviewers. Another document may absorb the useful mechanism. Implementations may have moved in a different direction. A dependency may be unresolved. The proposal may have attracted serious technical objections. Or contributors may simply be allocating limited time elsewhere. Each path can justify a change in the work set, but they are not interchangeable judgments about technical merit.

RFC 7282 explains why rough consensus cannot be reduced to a count of supporters. The quality of the reasons and whether objections have been addressed matter more than a show of hands. The same discipline should apply at exit. “Five people stopped posting” is not a complete disposition. Neither is “the chairs closed it” if the record omits the question put to the group, the objections considered and the reasons for the consensus assessment.

Nor does the document state reach directly into operating networks. A vendor may maintain code based on an abandoned draft. An operator may continue an experiment. Another standards venue may depend on the idea. Conversely, an active WG Document may have no production deployment at all. The institutional state answers who is working on the text under which authority. Deployment evidence answers what systems actually do.

This separation follows Heng Lu’s account of minimum initial specification, localized future decision and voluntary adoption. A coordination artifact can establish a common reference and a bounded decision process without commanding universal implementation. Applied here as an editorial lens, the point runs in both directions: adoption does not create a deployment mandate, and reversing adoption does not switch deployed systems off.

The safest public sentence is therefore narrow: The working group returned this Internet-Draft to non-adopted status on this date, for these recorded reasons. Any stronger conclusion needs its own evidence.

What a clean reversion must preserve

An exit state becomes trustworthy when a later reader can reconstruct the custody chain without asking the participants to remember it.

Start with identity. Record the individual draft that was considered, the draft-ietf document that replaced it, every relevant revision and the content hashes. Link the original adoption call and the chairs’ consensus announcement. Without those links, reversion can leave two apparently unrelated document families and invite a false duplicate or false continuity.

Then preserve the decision. The public record should show who proposed reversion, the interval allowed for discussion, arguments for and against continued WG custody, significant unresolved objections, and the chairs’ assessment. Waning interest should be supported by observable facts appropriate to the case—missing editors, unanswered review calls, superseding work or an explicit group response—not treated as a self-proving label.

Next, name the resulting state precisely. Is the draft non-adopted with no stream-specific state? Parked pending an editor? Dead but preserved? Replaced by another WG document? Transferred? Allowed to expire? Continued as an individual submission? Those outcomes create different expectations for authors, reviewers and dependent work.

The control handoff needs its own timestamp. Up to which revision were editors writing on behalf of the working group? When did later changes become author-controlled rather than WG-controlled? Which people remain editors, authors or maintainers, and under what representation? A filename alone cannot safely answer those questions.

Finally, separate the technical ledger from the disposition ledger. Open design issues, useful analysis, implementation reports and unresolved objections should survive even if the group stops the work. Reversion can release the WG’s future attention without erasing knowledge already produced. A decision to stop investing is not a licence to destroy the evidence needed by anyone who continues elsewhere.

The reversion receipt

A compact receipt should contain:

  1. the exact individual and WG draft names, revisions and hashes in the adoption chain;
  2. the adoption call, consensus announcement, date and reasons;
  3. the last revision under working-group change control;
  4. the reversion proposal, discussion dates and arguments on both sides;
  5. the chairs’ consensus assessment and dated disposition;
  6. the exact resulting document and stream state;
  7. the end of WG editor authority and the new control holder, if any;
  8. replacement, successor, transfer, individual or independent-submission links;
  9. preserved open issues, technical objections and reusable analysis;
  10. known implementation, deployment, experiment and downstream-document dependencies, with separate sources;
  11. any charter, milestone or Area Director consequence; and
  12. an explicit non-claim explaining that the transition is not automatically technical rejection, RFC withdrawal, repository deletion or operational shutdown.

This is more than administrative tidiness. Adoption changes who can speak for the document. Reversion changes that answer again. A system that records the first transfer but not the second grants stale institutional authority to text the group no longer owns. A system that deletes the first transfer rewrites history. The receipt avoids both mistakes.

Sources