時差ボケってキツイですね！（既視感）
GMOコネクトの菅野 哲（かんの さとる）でございます。
IETF124で最初に参加したセッションがDISPATCHでしたので、とりあえずまとめました！
ご覧いただけると雰囲気がわかるかと思います。
第2部：
この記事は「第1部：概要と主要トピック」の続きです。
1. DACP: Data Access and Collaboration Protocol
提案者: Ziang Zhou (リモート参加)
ドラフト: draft-shenzhihong-dacp-00
発表資料: スライド
1.1 提案概要：科学データの転送問題
科学分野の分散コンピューティングは、深刻なデータ転送問題に直面しています。TB/PB級のデータセットが世界中に分散し、統一的な発見メカニズムもなく、REST/JSONの高いシリアル化コストがリアルタイム処理を阻んでいます。
Ziang Zhouは、Apache Arrow Flightをベースとしたカラム型データ転送プロトコル「DACP」を提案しました。その核心的な機能は以下の通りです：
技術的特徴:
-
URIアドレッシング:
dacp://host:port/[dataset]/pathによる精密なアドレス指定 - 遅延計算: メモリに全データを読み込まず、オンデマンドでPBスケールのデータをスライシング
- カラム型ストリーミング: Apache Arrow形式でget/put/action/cook操作を実行
- 分散トークン認証: アクセス制御とトレーサビリティを実現
提案者は、HTTP/3やQUICでは不十分な科学データ転送の要件を満たし、既存のIETF技術の上に構築されているとして、ARTエリアの既存WGへの誘導を希望しました。
1.2 HTTPで十分という指摘
しかし、議論はすぐに本質的な疑問に直面しました。
Martin Thomsonは核心を突きました。「ドラフトを読んだが、プロトコル作業が本当に必要かどうか不明だ。これがHTTPとは別に何か新しいことをするのか分からない。理解する限り、ほとんどの機能はHTTPで問題なく動作する」。そして結論として、「この作業を引き受けないことを提案する」と明言しました。
Ted Hardieも同様の見解を示しました。「URIとポート番号の要求はIETFに属するが、残りの部分は既存ツールを使用している。この作業がIETFに属するとは確信できない。プロトコル作業は他の場所で進めることができる」。
1.3 非IETF技術への依存
さらに深刻な問題が指摘されました。プロトコルの基盤となる技術がIETFの管轄外だという点です。
Mike Bishopは（AD帽子を脱いで個人として）問題を整理しました。「これはApache Arrow（非IETF）の上に構築され、gRPC（非IETF）の上に構築されている。IETFでこれを標準化するには、まず構成要素を標準化する必要がある。IETFの外で行われるか、多くの前提作業を持ち込む必要がある」。
1.4 コミュニティの不在
Charles Eckelが実務的な問題を提起しました。「Apache Arrowプロジェクトのコミュニティは、これをIETFに持ち込むことに興味があるか？そのコミュニティからの人々がここにいることが重要だ」。
提案者の回答は心もとないものでした。「これまでApacheコミュニティと協力していないが、進めれば参加を説得できると考えている」。標準化を進める前に、まず関連コミュニティとの連携を確立すべきだという暗黙の批判がありました。
1.5 結論
DISPATCH結論: IETFでの作業不適当
DACPは3つの根本的な問題により、IETFでの標準化に適さないと判断されました：
- 既存技術で十分: HTTPで実現可能な機能を新プロトコルで実装する必要性が不明確
- 非IETF技術への依存: Apache ArrowとgRPCという構成要素がIETFの管轄外
- コミュニティの不在: Apache Arrowコミュニティとの事前調整がない
科学データ転送の課題は重要ですが、その解決策は必ずしも新しいIETFプロトコルではありません。むしろApache Arrowコミュニティで進めるか、既存のHTTP/3を活用する方が適切だという判断です。
2. AI Agent Discovery using DNS (BANDAID)
提案者: Jim Mozley (オンサイト参加)
ドラフト:
発表資料: スライド
2.1 提案概要：DNSでAIエージェントを発見する
AIエージェント間通信の時代において、エージェントをどう発見するか？Jim Mozleyの答えは、既存のDNSインフラの活用でした。
「Brokered Agent Network for DNS AI Discovery (BANDAID)」と名付けられたこの提案は、SVCBレコード、DNS-SD、DNSSEC、DANEといった既存のDNS技術を組み合わせます。重要なのは、DNSメッセージの構造変更も、新しいリソースレコードタイプも提案していない点です。既存のDNSプロトコル値を再利用する保守的なアプローチです。
2.2 「AI」は新しくない
しかし、Phillip Hallam-Baker (PHB)は根本的な疑問を投げかけました。
「全てに同意するが、一つ問題がある。BANDAIDは登録商標なので使用すべきでない」。技術的な議論の前に、商標問題が浮上しました。
PHBはさらに続けました。「IETFでは長年AIに取り組んできた。唯一違うのは用語だ。クライアント/サーバーを使用している。サーバーは『待つ側』、クライアントは『何かを開始する側』。AIを推進する人々に、既にこれがカバーされていると伝える以外に、何か違うことを提案しているようには見えない」。
これは痛烈な指摘です。「AI」という流行語に惑わされず、本質的にはクライアント/サーバー発見の問題だというのです。
2.3 既存技術の統合こそが課題
PHBはさらに建設的な指摘をしました。「現在、DANE/DANCE/DNS Service Discoveryという3つの異なるものがある。原則として1つにまとめられる可能性がある」。
つまり、新しい発見メカニズムを作るのではなく、既存の3つの技術を統合することこそが本当の課題かもしれません。
2.4 DNSに押し込むリスク
John Klensinは、DNS利用の隠れたコストを警告しました。
「DNSに押し込むことの1つの側面を指摘したい。DNSの全ての非技術的問題を継承する。識別、名前の所有者、責任といった問題だ。プライバシー懸念もあり、物事をより複雑にする。このアプリケーションがこれらの懸念を継承したいかどうか不明だ」。
技術的には機能しても、DNSのガバナンスモデルやプライバシー特性がAIエージェント発見に適しているとは限りません。
2.5 公式プロセスの重要性
Jonathan Rosenbergが議論の流れを変えました。「発見が議題に含まれるべきかは、明日のサイドミーティングで既に議論が予定されている」。提案者も「本日16:00にもこのドラフトを議論するサイドミーティングがある」と応じました。
しかしRoman Danyliw（GEN AD）が重要な指摘をしました。「サイドミーティングに送ると、IETFでの正式な位置づけがない。このミーティング(DISPATCH)が公式プロセスだ」。
サイドミーティングは非公式な議論の場に過ぎず、正式な意思決定はDISPATCHで行われるべきだという原則の確認です。
2.6 スコープの明確化が必要
Cullen Jenningsが核心的な質問をしました。「発見の要件のスコープを明確にすることが有用だ。エンタープライズ内か、インターネット全体か」。
提案者は「両方」と答えましたが、これが問題です。エンタープライズ内の管理された環境と、インターネット全体のオープンな環境では、セキュリティ、プライバシー、スケーラビリティの要件が全く異なります。
2.7 結論
DISPATCH結論: BoFの推奨
Jonathan Rosenbergが「サイドミーティングからBoFを提案する」と述べ、BoF開催が推奨されました。
BoFで議論すべき課題:
- 名称変更: 「BANDAID」は登録商標であり使用不可
- スコープの明確化: エンタープライズ vs インターネット全体
- 既存技術との関係: DANE/DANCE/DNS-SDの統合可能性
- DNSの非技術的問題: ガバナンス、所有権、プライバシー
- 新規WG vs 既存WG: Dnsopでの作業か、新規WG設立か
PHBの「AIは新しくない」という指摘は重要です。本質的にはクライアント/サーバー発見の問題であり、既存の3つのDNS技術の統合こそが真の課題かもしれません。BoFでこの視点から議論が深まることが期待されます。
3. Customer-Facing Relay (CFR): Source Privacy
提案者: Gianpaolo Scalone (オンサイト参加)
ドラフト: draft-scalone-cfr-source-privacy-00
発表資料: スライド
3.1 提案概要：残されたプライバシーギャップ
TLS 1.3とECH（Encrypted Client Hello）により、宛先プライバシーは大きく向上しました。しかし重要なギャップが残っています。クライアントのIPアドレス（ソース）は依然としてCDNやホスティングプロバイダーに可視であり、メタデータ相関によるプロファイリングが可能です。
Gianpaolo Scaloneは、ネットワークエッジ（ISP/企業）に軽量リレー「Customer-Facing Relay (CFR)」を設置することを提案しました。ユーザーアイデンティティを宛先から分離しながら、追加ホップを避けることでレイテンシを最小化する、持続可能なアプローチだと主張します。
3.2 既存技術で実現可能では？
Tommy Paulyは、問題認識には同意しつつ、解決策に疑問を呈しました。
「ECHが十分でなく、サーバーがIPを見られるというプライバシーストーリーに同意する。IABにはプライバシー分割に関する声明もある。しかし質問だ。『これは既存の作業とどう違うのか？』 ドラフトは詳細が薄いように見える」。
彼は具体的な代替案を示しました。「ネットワークホスト型MASQUEプロキシがこれを実現でき、プロキシ発見に関する進行中の作業もある。MASQUEまたはINTAREAと連携することを勧める」。
提案者は差別化を試みました。「これは異なる。持続可能なアプローチを求めている。追加要素を加えるとレイテンシが増加する。既存のネットワーク要素を改善したい」。しかし、この説明では既存技術との本質的な違いが不明確でした。
3.3 「これはNATだ」
Martin Thomsonの指摘はさらに辛辣でした。
「多くの人が私の後でOblivious HTTPについて話すだろう。しかしこれはNATを記述していると思う。IETFが長い間その概念を拒否してきたのは興味深い。既に多くの場所で展開されている」。
NAT（Network Address Translation）は、まさにクライアントIPをサーバーから隠す技術です。CFRとNAT/CGNATの本質的な違いは何なのか？
Martinはさらに続けました。「問題は、多くのネットワークがNATの展開を望んでいないことだ。オペレーターがこれを運用することに興味があるかが重要。IETFなしでもこれを実行できる。多くのオペレーターは既にCGNATを実行している」。
つまり、技術的には既に実現可能であり、問題はオペレーターの運用意欲だということです。
3.4 技術選択が先決
Dennis Jacksonが本質を突きました。「これがどの技術を使用するかが本当に重要。まずそれを決定する必要がある」。
アーキテクチャの議論の前に、MASQUEなのか、Oblivious HTTPなのか、それとも全く新しいアプローチなのか。技術選択を明確にしない限り、建設的な議論は不可能です。
3.5 監視脅威への着目
Andrew Camplingは、提案の動機に着目しました。「CDNの監視脅威は興味深いと思う。専用メーリングリストにディスパッチして、よりスコープを明確にし、後でBoFはどうか？」。
プライバシーギャップの存在自体は認識されています。問題は、その解決策として何が適切かです。
3.6 結論
DISPATCH結論: 専用メーリングリストでの追加議論
議長の判断で、専用メーリングリストでの議論となりました。そこで明確にすべき課題は：
技術的な差別化:
- MASQUEとどう違うのか
- Oblivious HTTPとどう違うのか
- NAT/CGNATとどう違うのか
運用面の実現可能性:
- ネットワークオペレーターの運用意欲
- レイテンシと持続可能性のトレードオフ
- 既存インフラへの統合方法
スコープの明確化:
- どのプライバシー脅威を対象とするのか
- どのような環境（ISP、企業等）を想定するのか
Martinの「NAT」という指摘と、Dennisの「技術選択を先に決定」という指摘が核心です。既存技術との明確な差別化ができなければ、新しいプロトコルの必要性は示せません。
4. The Longfellow Zero-knowledge Scheme
提案者: Tim Geoghegan (オンサイト参加)
ドラフト: draft-google-cfrg-libzk
発表資料: リンク
4.1 提案概要：プライバシーを守る年齢確認
英国とEUで年齢確認義務化が進む中、従来の方法（ID写真のアップロード等）は深刻なプライバシーリスクを伴います。Longfellowは、ゼロ知識証明（ZK）により、必要最小限の情報（例：18歳以上であること）だけを証明し、他の情報（生年月日、名前、住所等）を開示しない技術です。
技術的特徴:
- mDOC（mobile Driving License）との互換性
- レガシー暗号（ECDSA、SHA-256）に最適化
- Google Walletで既に展開されている
実装が先行している技術の標準化という、興味深いケースです。
4.2 「政府は待ってくれない」
Eliot Learが緊急性を訴えました。
「緊急性を加えたい。スイスに住んでいるが、先月、電子IDの投票があった。50.4%で可決された。議論はあったが前進している。政府は待ってくれないので、前進してほしい」。
標準化には時間がかかりますが、政府の規制は待ちません。50.4%という僅差でも、一度可決されれば実施されます。
提案者も現実を認めました。「緊急性について、MIMIでも出てきた。IETFが可能な限り速く動いても、それでも速くはない」。
4.3 感情的なトピックへの警戒
しかし、Mark Nottingham（IABワークショップ共同議長）は慎重な姿勢を示しました。
「レポートを作成する。多くのことが起こったので少し時間がかかる。複雑なトピックで、多くの要素と多くの関係者がいる。単に技術を定義するだけではない」。
そして核心的な懸念を述べました。「同時に、メーリングリストの作成について。これは非常に感情的なトピックだ。リストは非常に非生産的な議論の場になる可能性がある。『このリストで年齢確認を議論する』と言うのは少し警戒している」。
年齢確認は、子供の保護、表現の自由、プライバシー権など、複数の価値が対立する領域です。技術的な議論が政治的・感情的な議論に飲み込まれるリスクがあります。
4.4 [火災報知器が鳴る]
議論の最中、[FIRE ALARM WENT OFF] と議事録に記録された通り、火災報知器が誤作動しました。提案者は「明日も16:30にサイドミーティングがある」と告知し、議論は中断しました。
[中断: 火災ハンドルが誤って引かれた]
4.5 複数の選択肢
火災報知器の誤作動の後、議論が再開されました。様々な選択肢が提示されました。
暗号エンジニアリングWG（新設）
Deirdre Connollyの提案です。「これは既に業界で仕様化されているもう一つのケース。居場所が必要だ。Independent EditorとIRTFは適切な場所ではない。暗号エンジニアリングのワーキンググループが適切かもしれない」。
Longfellowだけでなく、既に展開されている他の暗号技術の標準化も扱うWGという構想です。Alyssa Cooperも「ワーキンググループは自然な適合で、Informationalとして文書化できる」と支持しました。
ADスポンサーによるInformational
Rohan Mahyは実務的な提案をしました。「これは実運用されている。存在を文書化したいか？ADスポンサーまたはInformational。また、BoFについて、スコープすら分からない」。
標準化ではなく、既存実装の文書化に焦点を当てる方が現実的かもしれません。
CFRGでの作業
Eric Rescorlaは「興味深い作業だが、signalよりはるかに複雑。メカニズムはCFRG」と示唆しましたが、Eliot Learが懸念した「物事がゆっくり進む」という問題があります。
4.6 年齢確認以外のユースケース
Martin Thomsonが重要な質問をしました。
「コンパイラまたは回路がスコープに含まれるかという質問。回路は標準化が必要だ。年齢確認に焦点が当てられているようだが、作業の動機付けに使うべき理由とは思わない。CFRGで既に進行中のより効率的な代替ゼロ知識証明がある。もっと質問に答えてほしい。年齢確認以外のユースケースはあるか？」
年齢確認という感情的なトピックに縛られず、より広いZK証明技術として位置づけるべきではないか。この質問は、標準化のスコープを考える上で重要です。
4.7 結論
DISPATCH結論: 議長団がADsと協議
結論は先送りとなりました。以下の理由から、即座の判断が困難だったためです：
複雑な要素:
- 実装が先行 - 標準化前に既にGoogle Walletで展開
- 政府規制の時間軸 - 標準化を待たずに規制が進行
- 感情的なトピック - 年齢確認という政治的に敏感な問題
- 複数の選択肢 - 暗号エンジニアリングWG、ADスポンサー、CFRG、BoF
- スコープ不明確 - 年齢確認に特化 vs ZK証明技術全般
次のステップ:
- IABワークショップ報告書（年末予定）
- 木曜日のIAB公開ミーティング
- ADsとの協議で方向性決定
Richard Barnesの「Martinのコメントで納得した。ワーキンググループに向けて焦点を当てるべき。待つ必要はない」という発言と、Robertaの「政府が物事を行っている。BoFを提案」という発言が、緊急性と慎重さの間のジレンマを象徴しています。
5. まとめと次回予告
本記事では、AI・プライバシー関連の4つの提案について詳細な議論内容を報告しました：
DACP:
Apache ArrowとgRPCという非IETF技術への依存、HTTPで十分という指摘、Apache Arrowコミュニティとの連携不足により、IETFでの作業不適当と判断されました。科学データ転送の課題は重要ですが、解決策は必ずしも新しいIETFプロトコルではありません。
BANDAID:
BoF推奨となりましたが、商標問題、スコープの不明確さ、既存技術（DANE/DANCE/DNS-SD）との関係など、多くの課題が残されています。PHBの「AIは新しくない」という指摘は、本質的にはクライアント/サーバー発見の問題であることを示唆しています。
CFR:
専用メーリングリストでの議論となりましたが、Martinの「NAT」という指摘、Dennisの「技術選択を先に」という指摘が核心です。既存技術（MASQUE、Oblivious HTTP、NAT/CGNAT）との差別化が明確でない限り、新しいプロトコルの必要性は示せません。
Longfellow:
複数のシナリオが検討され、結論は先送りとなりました。実装が先行する標準化、政府規制の時間軸、年齢確認という感情的なトピック。これらの複雑な要素が絡み合い、即座の判断を困難にしています。火災報知器の誤作動も印象的なエピソードでした。
第3部: 技術詳細（暗号・セキュリティ編） では、残りの3つのトピックについて報告します：
- Post-Quantum Guidance for IETF Protocols
- A Standard for Claiming Transparency and Falsifiability (TMIF)
- TESLA Update for GNSS SBAS Authentication
特にPost-Quantum Guidanceでは、Eric Rescorlaの「/dev/null」提案やPaul Woutersの「over my dead body」発言など、さらに激しい議論が展開されました。
乞うご期待です？
最後に、GMOコネクトでは研究開発や国際標準化に関する支援や技術検証をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。