Summary

  • Revision 00-01 of the proposed IETF Agent Communication Protocols charter appeared on 14 September. It remains under internal Steering Group/IAB review and is listed for the 17 September IESG telechat; Agentproto is not yet a chartered working group.
  • The revision adds coordination with relevant standards and open-source efforts outside the IETF to understand deployed practice and avoid unnecessary divergence.
  • The preceding sentence says proposed changes to protocols owned by other IETF working groups will be raised with those groups for decisions. External practice and internal decision authority therefore enter the text through different lanes.
  • Daniel Kade proposes a two-lane coordination receipt that records exact outside artifacts and their disposition without treating consultation as delegation. That receipt is not a requirement of the proposed charter.

Two adjacent sentences, two different verbs

The current proposed charter would give Agentproto a baseline protocol for managing dialogs among users, agents and tools, plus a reference architecture and use-case material. Near the end of the deliverables, it handles dependencies in two adjacent sentences.

The first concerns IETF-owned work. If Agentproto needs a change or extension to a protocol specified by another IETF working group, the issue would be raised with the relevant group “for decisions on how best to handle” it. Agentproto would not silently appropriate another group's change control.

The next sentence is new in revision 00-01. It says the group would coordinate with relevant standards and open-source efforts outside the IETF to understand deployed practice and avoid unnecessary divergence.

Both lanes matter. Implementations can reveal constraints that a clean architecture misses. External specifications may already define identity, authorization, encryption or agent-interaction components. Open-source projects can expose whether two theoretically compatible choices actually interoperate. Ignoring those facts would make an IETF protocol less useful.

But the verbs are not interchangeable. To coordinate, observe and understand is not to transfer a decision. Conversely, an IETF decision about its own deliverable does not give the IETF power to rewrite an outside project's roadmap. The proposed text is most defensible when that symmetry is preserved in the public record.

Revision 00-01 is a live proposal, not a completed mandate

The Datatracker record identifies the document as a proposed charter in “Start Chartering/Rechartering (Internal Steering Group/IAB Review).” It is on the agenda of the 17 September IESG telechat. Those facts show movement through a formal review path. They do not show approval, establishment of a working group or consensus on a standard.

The change from 00-00 to 00-01 is narrow but visible. The definition of an AI agent loses the adjective “intelligent.” A security paragraph now covers data exchanged between agents and users as well as other agents and tools. One grammatical error is corrected. The external-coordination sentence is added.

The charter history and ballot record add context. On 10 September, one ballot comment asked whether the prospective group should collaborate with non-IETF groups. Another raised the user-facing security omission and requested milestones that track later progression. The history records a March 2028 submission milestone on 13 September and revision 00-01 on 14 September.

The correspondence is worth reporting; causation is not. The public history checked here does not attach each changed line to a disposition saying which comment produced it, who accepted it, or why. “A comment preceded a matching edit” is evidence of sequence. It is not a licence to invent an edit decision.

This distinction also separates the present event from the IETF 126 BoF. That meeting tested several different questions about scope, deliverables and forming a group. Revision 00-01 is a later proposed text in the chartering path. It should not be made to retroactively merge or reinterpret those room counts.

External evidence does not arrive with an authority upgrade

The IETF already has a mature language for formal inter-organizational contact. RFC 4052 places liaison relationships under IAB management, asks that they remain as informal as practical and describes their value in avoiding duplicate work without obstructing either organization's mandate.

RFC 4691 makes the authority limit sharper. A liaison manager is a bidirectional communications channel. The manager gathers the information that the IETF needs, but may convey an IETF position only after the relevant consensus is understood. A personal view does not become an IETF view because its speaker holds a liaison role.

RFC 4053 gives liaison statements a routing and response discipline. A request that seeks to influence a working group's direction receives appropriate consideration, like other temporary documents; it does not arrive pre-approved. A deadline may make the response urgent, but urgency does not create substantive authority.

These RFCs should not be stretched into a requirement that every Agentproto exchange with an open-source maintainer become a formal liaison. The new charter sentence deliberately covers a wider universe of standards and open-source efforts. Much useful coordination may happen through public issues, drafts, implementation reports, interop events or ordinary IETF participation.

The transferable principle is smaller: preserve the source, version, channel and institutional status of an input, then show the IETF act that considered it. That lets a formal liaison remain formal, an individual contribution remain individual and a repository experiment remain implementation evidence.

A two-lane coordination receipt

For each material dependency, Agentproto could publish one compact row. The input lane would name the issue, external artifact, exact version or commit, steward, channel, date, claim and verification state. It would say whether the record was a formal liaison statement, an organization-level position, an individual contribution, an implementation observation or an unresolved report.

The decision lane would name the Agentproto deliverable affected, the responsible IETF owner, the discussion URI, the current state and the rationale. A controlled disposition vocabulary could include observed, considered, adopted, adapted, rejected, deferred and external-owner-action-requested.

Where another IETF working group owns the affected protocol, the row should link to that group's decision record rather than implying that Agentproto decided for it. Where the external project owns the necessary change, the row should show that Agentproto requested or awaited outside action rather than presenting the request as an order.

Any outgoing communication that claims to speak for the IETF should carry its consensus status. Any implementation result should carry its tested versions and limits. The receipt need not publish private security detail or personal correspondence. It must publish enough provenance to stop three common substitutions: a prominent participant for an institution, consultation for consent, and an implementation's popularity for an IETF decision.

This proposal is not hidden in the charter. It is an editorial recommendation for making the charter's own two-lane structure observable.

Sources

  1. Agentproto proposed charter 00-01 with milestones
  2. Agentproto proposed charter 00-00 with milestones
  3. Agentproto charter history
  4. Agentproto charter ballot
  5. Agentproto proposed-charter record
  6. RFC 4052 — IAB Processes for Management of IETF Liaison Relationships
  7. RFC 4053 — Procedures for Handling Liaison Statements
  8. RFC 4691 — Guidelines for Acting as an IETF Liaison
  9. RFC 2418 — IETF Working Group Guidelines and Procedures
  10. RFC 5434 — Considerations for Having a Successful BoF Session
  11. Lu Heng — The Multi-Stakeholder Mirage
  12. Lu Heng — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption