Summary

  • On 27 August 2026, DAWN remained a Proposed group. Its 00-00 charter was in internal IESG/IAB review, and the ballot asked only whether the text was ready for external review.
  • NETCONF was already Active, but 20-02 was a proposed recharter. Datatracker expressly identified version 20 as the current approved charter.
  • RFC 2418 makes an approved charter a bounded institutional contract for a specific set of tasks. Drafting, internal review, community review, IESG approval and Secretariat announcement are separate acts.
  • Even an approved charter authorizes a problem space, not a particular Internet-Draft, technical conclusion, RFC or operational deployment.

One latest pointer can fail in two directions

Text revision and institutional effect are different clocks. A diff can show that a sentence was added on Tuesday. It cannot show that the body empowered to approve the sentence acted on Tuesday, or that the approved text took effect then.

That distinction behaves differently at formation and rechartering. Before an initial charter is approved, there is no working-group authority to update. The correct current-charter value is not the proposal; it is explicitly empty. During rechartering, an institution and an approved scope already exist. The correct current-charter value remains the old approved version until a recorded decision replaces it.

A service that keeps only the newest document therefore commits opposite errors with the same rule. It manufactures a mandate for a group not yet formed, while prematurely withdrawing the limit on a group that is already active. A reliable register needs two independent references: latest proposal and current approved charter.

This is not clerical neatness. If proposed scope is presented as current, meetings begin to allocate attention to it. Individual submissions acquire the appearance of working-group direction. Adjacent groups and other standards bodies defer. Product teams describe anticipated IETF work as settled. A later revision can repair a page, but it cannot recall code, procurement language or organizational expectations already built around the premature claim.

DAWN had a reviewable proposal, not an approved group

The DAWN group page carried the heading “Proposed WG Discovery of Agents With Names” on the observation date. Its state was Proposed; its charter was charter-ietf-dawn-00-00; and the process state was Start Chartering/Rechartering (Internal Steering Group/IAB Review).

The text was substantial. It described discovery of AI agents and resources, distinguished local, intra-organizational and inter-organizational settings, identified possible mechanisms, named proposed chairs, set deliverables and dates, and excluded several identity, trust and Internet-wide indexing questions from the initial scope. Detail made the proposal capable of review. Detail did not make it effective.

The charter ballot supplied the most important qualifier in the form of its question: “Is this charter ready for external review?” Éric Vyncke had recorded Yes. Mohamed Boucadair had recorded a Block. Other listed members showed No Record, and the summary said the proposal had enough positions to pass this stage once the Block was resolved.

Boucadair's comment was supportive of doing the work while asking for sharper boundaries. It questioned the trigger and operational model for discovery, the differences between local and inter-organizational cases, the relevant trust guards, and whether one protocol could sensibly cover the stated environments. That is evidence of a scope objection under review. It is neither a final rejection of DAWN nor proof of a permanent individual veto.

A Yes must be kept equally narrow. Removing the ballot question converts “ready to expose to wider review” into “approved to operate”. The DAWN history records the 00-00 text, creation of the ballot and entry into internal review on 24 August, followed by the Block on 25 August. It does not record final formation.

The July IETF 126 BoF agenda reinforces the distinction. Participants had already developed terminology, use cases, requirements and a candidate charter. The BoF supplied evidence that a problem and a community might exist. It did not transfer the IESG's formation decision to the people in the room.

DAWN may later be approved, revised, returned or abandoned. This article predicts none of those outcomes. A future approval can create authority from its attributable effective point forward; it cannot make the preparatory period retroactively authorized working-group activity.

NETCONF kept its approved boundary during review

NETCONF began from the opposite side of the line. Its working-group page identified it as Active, with an established field around NETCONF, RESTCONF, YANG and network management.

The charter page showed charter-ietf-netconf-20-02, last updated on 12 August, in internal review as a rechartering action. It also printed the decisive sentence: the information shown was for a proposed recharter, and the current approved charter was version 20.

Three objects therefore coexisted. NETCONF was the active institutional container. Version 20 was its current approved scope. 20-02 was a request to change that scope. Reviewing the request did not suspend the old charter, and publishing a more recent revision did not grant ordinary working-group status to the additions.

The NETCONF ballot asked the same limited question about readiness for external review. Christopher Inacio retained a Block because the proposal had no milestones. Mahesh Jethanandani recorded Yes, several members recorded No Objection, and the summary said the ballot could pass once the Block was resolved. None of those facts changed which charter was operative that day.

If the IESG requests changes, a later proposal may become the real candidate. If the effort is withdrawn, version 20 continues. If a new charter is approved, the decision and announcement can identify the final text, the version it replaces and the effective time. No outcome requires pretending that 20-02 became law for the group on publication.

Premature replacement also reverses the burden of proof. Before approval, proponents must show why additional work belongs in NETCONF. Once meetings, adoption calls and implementations have accumulated under a shadow scope, reviewers are pressed to justify “taking away” an authority that was never granted. Review of an application becomes ratification of sunk cost.

RFC 2418 assigns the decision; it does not erase participation

The published baseline on the observation date remained RFC 2418, part of BCP 25. It describes working groups as the IETF's primary mechanism for developing specifications and guidance, ordinarily formed around a specific problem and set of deliverables.

The proposed chair and relevant Area Director normally negotiate the charter. The IAB provides advice, and the IESG gives final approval. After internal examination, proposed text is exposed to wider community review. The IESG may approve it, change it or decline to form the group. Following approval, the Secretariat records and announces the group.

RFC 2418 calls the charter a contract between the IETF and the working group for a set of tasks. “Contract” here is an institutional allocation of work, not a commercial agreement, a treaty or a political delegation from every person affected by the technology. It joins a public forum, procedural management and a bounded scope.

The boundary has operational consequences. Chairs can defer out-of-scope input while preserving openness and progress. Area Directors can pursue rechartering, leadership changes or closure when assumptions or tasks change. Neighboring groups can identify overlap. Other standards bodies can decide whether liaison is needed. Potential contributors can decide where to invest effort.

RFC 3710 clarifies the distribution of roles. An initiative may originate with participants or an Area Director. Prospective chairs make a tractable plan. Participants demonstrate expertise, interest and objections. The IAB examines architectural implications. Wider review exposes privacy, security, operational and jurisdictional consequences. The Area Director coordinates these interfaces. The IESG takes responsibility for the institutional decision.

Saying that participation is not authorization does not make review ceremonial. A strong objection can change the proposed scope, add a liaison, split a deliverable or show that a group is not ready. Review gives the decision-maker evidence and leaves a public account. It is valuable precisely because it informs a decision without pretending that attendance itself creates a mandate.

Approval of a forum is not approval of an answer

A charter decides which questions a working group may organize. It does not select the technical answer before the group begins.

The sequence has several independent steps. Exploration can produce individual drafts. An approved charter can establish a working-group container. A working group can adopt one Internet-Draft as a basis for work without agreeing with all of its contents. Rough consensus and Working Group Last Call are later judgments. IESG evaluation is another act. RFC publication gives a stable document identity, while stream and category determine what status the RFC actually has.

Deployment remains further away. RFC 3935 describes an IETF that develops useful engineering documents but cannot compel their use across the Internet. An operator still needs a selected version, an accountable owner, test evidence, change scope, rollback conditions and observations from running systems.

The distinction is visible even in the proposed successor to RFC 2418. draft-ietf-procon-2418bis-04 was an active PROCON WG Document on 27 August, with IESG state I-D Exists. Its header says it would obsolete RFC 2418 and RFC 3934 if approved. The condition is part of the fact.

The draft text describes a charter as a commitment to scope and expressly says that adopting an Internet-Draft makes it a basis for work rather than demonstrating consensus on its contents. The PROCON charter authorizes consolidation of a named process-RFC chain and limits other substantive work absent rechartering. That authority to develop a successor does not approve the successor in advance.

RFC 9281 maps the separate entities involved in the standards process. A durable governance record must preserve those separations instead of compressing them into a badge marked “IETF”.

The handoff needs a receipt

A trustworthy charter record should first name the action: INITIAL_CHARTER or RECHARTER. It should store group state, proposal identifier, revision and exact text fingerprint. A separate field should contain the current approved charter and its fingerprint, or an explicit null for a group not yet formed.

The scope record should identify additions, removals, retained work, exclusions, deliverables, neighboring groups and external coordination. The review record should preserve the responsible Area Director, proposed or current chairs, opening date, exact ballot question, every position, each Block and its resolution, IAB advice, the external-review announcement and disposition of material comments.

The decision record should identify the IESG outcome, public reasoning, date, Secretariat announcement, effective time and the old charter replaced. Approval, return for changes, continuation under the old charter, withdrawal, decline and disbandment all need express states.

Each approved charter should travel with two negative assertions: it does not show consensus on a specific document, and it does not command implementation or deployment. Those limits do not weaken the charter. They make its real authority portable without inflation.

Sources

  1. IETF Datatracker: groups currently chartering or rechartering
  2. IETF Datatracker: proposed DAWN working group
  3. IETF Datatracker: DAWN charter ballot
  4. IETF Datatracker: DAWN charter history
  5. IETF Datatracker: IETF 126 DAWN BoF agenda
  6. IETF Datatracker: NETCONF proposed recharter
  7. IETF Datatracker: approved NETCONF charter version 20
  8. IETF Datatracker: active NETCONF working group
  9. IETF Datatracker: NETCONF charter ballot
  10. RFC 2418: IETF Working Group Guidelines and Procedures
  11. RFC 3710: An IESG Charter
  12. RFC 6292: Requirements for Working Group Charter Tools
  13. IETF Datatracker: draft-ietf-procon-2418bis status
  14. IETF Datatracker: draft-ietf-procon-2418bis text
  15. IETF Datatracker: PROCON working-group charter
  16. RFC 3935: A Mission Statement for the IETF
  17. RFC 9281: Entities Involved in the IETF Standards Process