要点

  • IETFのAgent Communication Protocols憲章案00-01が9月14日に公開された。現在もSteering Group/IABの内部レビュー段階で、9月17日のIESGテレチャット議題に載っているにすぎず、Agentprotoはまだ正式なワーキンググループではない。
  • 改訂版は、展開済みの実態を把握し不要な分岐を避けるため、IETF外の関連する標準化活動やオープンソース活動と連携すると追記した。
  • その前の文は、他のIETFワーキンググループが定めたプロトコルの変更を当該グループの判断に委ねる。外部情報の入口とIETF内の決定経路は別である。
  • Daniel Kadeは、この二つを結ぶ「二経路の連携レシート」を提案する。これは憲章案に書かれた要件ではない。

外を見る文と、決定者を示す文

00-01の本文は、将来のグループに三つの成果を想定する。ユーザー、エージェント、ツールの対話を維持する共通プロトコル、関連技術を組み合わせる参照アーキテクチャ、そしてユースケースと要件の文書である。

成果物の記述の末尾に、依存関係を扱う二つの文が並ぶ。Agentprotoが他のIETFワーキンググループのプロトコルを変更、拡張する必要がある場合、その問題は担当グループに持ち込み、どう扱うかを同グループが決める。隣接領域を扱うことは、既存プロトコルの変更管理を引き継ぐことではない。

続く新しい文は、関連するIETF外の標準化活動とオープンソース活動との連携を求める。目的は、実装・運用の実態を理解し、意味のない技術的分裂を避けることだ。

外部の実装は単なる参考資料ではない。アーキテクチャの前提が現実に合わないことを示したり、認証や認可の既存部品を提示したり、二つの方式が接続できないと実証したりする。採用判断の質を高める重要な証拠になり得る。

しかし、証拠の重さと決定権の所在は別問題だ。外部プロジェクトが協議に加わっただけでIETFの合意を取得するわけではない。IETFの判断も、外部リポジトリーの仕様やロードマップを直接変更しない。双方の自律性を残すからこそ、連携が長続きする。

00-01は到達点ではなく審査中の版

Datatrackerの記録では、文書は「Start Chartering/Rechartering (Internal Steering Group/IAB Review)」にある。9月17日のIESGテレチャット予定も表示される。審査日程は手続の進行を示すが、承認結果ではない。

00-00との差分は小さい。AIエージェントの定義から intelligent が削除され、保護すべき通信先にユーザーが加わった。文法上の修正が一つ入り、外部連携の文が追加された。

履歴と投票記録には、その前段が残る。9月10日のコメントの一つは非IETF団体とも協働すべきかを尋ねた。別のコメントはユーザーとの通信保護と、成果の進捗を追うマイルストーンに触れた。13日には2028年3月にプロトコル案をProposed StandardとしてIESGへ提出するマイルストーンが追加され、14日に00-01が出た。

ここで確認できるのは時系列と文言の対応までだ。各コメントを誰がどう判断し、どの編集に結びつけたのかという逐条の処理表は公開ページにない。したがって「質問の後に対応する変更が現れた」とは言えても、「この質問がこの修正を生んだ」と断定はできない。

また、今回の改訂をIETF 126のBoF投票の再解釈に使うべきではない。BoFでは範囲、成果物、グループ設立について異なる問いが置かれた。00-01はその後の憲章化手続にある提案文であり、過去の複数の数字を一つの委任状に変えるものではない。

リエゾン制度が示す権限の上限

RFC 4052は、IETFの正式なリエゾン関係をIABの管理下に置く。関係は実用上可能な限り非公式に保ち、双方の組織が自らの使命を遂行することを妨げずに重複を避ける、と説明する。

RFC 4691では、リエゾン担当者は双方向の情報経路である。外部の状況をIETFへ運ぶ一方、IETFを代表する発言は確認された合意に基づかなければならない。担当者個人の見解は、役職だけではIETFの意思にならない。

RFC 4053は、リエゾン文書の受領、割当て、検討、回答を扱う。ワーキンググループの方向に影響を求める文書は適切に検討されるが、送り手の肩書によって自動採用されることはない。期限は回答の緊急度を上げても、内容の権限を増やさない。

もっとも、Agentprotoとオープンソース保守者との全会話を正式なリエゾン文書にすべきだという話ではない。公開issue、相互接続試験、実装報告、個人としてのIETF参加など、軽い経路の方が適切な場合は多い。重要なのは、経路を通った途端に情報の身元を変えないことである。

二経路を一枚で追う

入力側には、課題、外部成果物、正確な版やcommit、管理主体、日付、経路、主張、検証状態を記録する。さらに、正式なリエゾン文書、組織見解、個人提案、実装観測、未確認報告を区別する。

決定側には、影響を受けるAgentproto成果物、IETF内の担当、公開議論、状態、理由を置く。状態は 観測済み、検討済み、採用、修正して採用、不採用、保留、外部管理者へ対応依頼 といった限られた語で足りる。

他のIETFグループがプロトコルを管理しているなら、そのグループの決定記録へ接続する。外部プロジェクトの変更が必要なら、命令ではなく依頼と独立した回答を記す。IETFを代表する対外文書には、それを裏付ける合意状態も付ける。

すべての雑談を保存する必要はない。機密性の高い脆弱性情報も公開しなくてよい。残すべきなのは、誰が何を提示し、誰が検証し、誰が決定でき、何が未決なのかである。このレシートはDaniel Kadeの提案であり、00-01本文の義務ではない。

情報源

  1. Agentproto憲章案00-01（マイルストーン付き）
  2. Agentproto憲章案00-00（マイルストーン付き）
  3. Agentproto憲章案の履歴
  4. Agentproto憲章案の投票記録
  5. Agentproto憲章案のDatatrackerページ
  6. RFC 4052：IETFリエゾン関係を管理するIABの手続
  7. RFC 4053：IETFとのリエゾン文書を扱う手続
  8. RFC 4691：IETFリエゾン担当者の指針
  9. RFC 2418：IETFワーキンググループの指針と手続
  10. RFC 5434：BoFを成功させるための考慮事項
  11. Lu Heng — The Multi-Stakeholder Mirage
  12. Lu Heng — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption