[PROCON-2026BIS-03][STATUS: EXPERIMENTAL][CATEGORY: PROCESS-REV]
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
RFC 2026bis: Modernized Internet Standards Process (draft-ietf-procon-2026bis-03)
【背景と設計目標】
1996年に規定されたRFC 2026（Internet Standards Process）は、近年の迅速な技術革新とリモート主体の標準化活動において、合意形成（Consensus）の遅延が課題となっていた。本ドラフト（procon-2026bis）は、マニュアルなメーリングリスト運用をデジタル署名に基づいた「Active Consensus Monitoring (ACM)」プロトコルで置き換え、標準化プロセスの透明化と高速化を目的とした新規設計である。
【通信シーケンスと動作】
ACMプロトコルは、ワーキンググループ（WG）参加者、チェア、およびIETF Datatracker（中央レジストリ）間での多段階合意を管理する。
sequenceDiagram
participant "P as WG Participant (Node)"
participant "C as WG Chair (Aggregator)"
participant "D as IETF Datatracker (Registry)"
Note over P, D: Consensus Phase Initiation
C ->> P: Consensus Request (Draft-ID, Seq-Num)
P ->> P: Verify Draft Integrity & Local Policy
P ->> C: Consensus Token (Signed Vote + Metadata)
C ->> C: Aggregate Proof-of-Consensus (PoC)
C ->> D: Submit PoC (HMAC-SHA256)
D -->> C: Transaction Confirmed (Block-ID)
D -->> P: Public Status Update (I-D State Change)
Request: チェアが特定のドラフトに対する合意形成フェーズを開始。
Token: 各参加者が自身の秘密鍵を用いて暗号化された合意トークンを送信。
Aggregation: チェアがトークンを集計し、しきい値（Rough Consensus）に達したことを証明するPoCを生成。
Confirmation: DatatrackerがPoCを検証し、ドラフトのステータスを自動更新する。
【データ構造 / パケットフォーマット】
合意形成に使用される「Consensus PDU」の構造は以下の通り。トランスポート層にはTLS over TCP/HTTP3を想定。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Packet Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Draft Identifier (64-bit) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Consensus Vec | Auth Algorithm| Signature Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Digital Signature / Auth Data / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version: プロトコルバージョン（0x03）。
Packet Type: Request(0x01), Response(0x02), Commit(0x03)。
Consensus Vec: 賛成・反対・棄権・技術的留保（Abstain with technical concerns）を示すビットフィールド。
Digital Signature: Ed25519等を用いた、参加者のIdentity証明。
【技術的な特徴と比較】
従来のRFC 2026プロセスと、ACMを用いた2026bisの比較。
| 特徴 | RFC 2026 (Traditional) | 2026bis (Modernized/ACM) |
|---|---|---|
| 合意形成の媒体 | メーリングリスト (Humming) | デジタル署名付きPDU (ACM) |
| 透明性 | 議事録に依存（主観的） | 公開台帳による検証可能（客観的） |
| レイテンシ | 数週間（Last Call待ち） | 準リアルタイム（0-RTT再送対応） |
| HOL Blocking | 前工程の承認待ちで全停止 | 並列タスク管理 (Stream-based) |
| 整合性チェック | 手動 (AD/Shepherd Review) | 自動 (CI/CD連携・プロトコル検証) |
【セキュリティ考慮事項】
リプレイ攻撃耐性: 各PDUにはTransaction IDとタイムスタンプが含まれ、一度使用された合意トークンの再利用はDatatracker側で破棄される。
シビル攻撃（Sybil Attack）対策: IANA/IETFで管理される「Authoritative Identity Certificate」を持つノードのみが有効な合意トークンを発行可能。
前方秘匿性 (PFS): 合意セッションの鍵交換にはECDHEを使用し、将来的にノードの鍵が漏洩しても過去の合意プロセスの秘匿性を維持する。
ダウングレード攻撃: ACM非対応の旧式メーリングリストプロセスへの強制移行を防ぐため、ドラフトのメタデータ内に「ACM-Required」フラグを義務化。
【まとめと実装への影響】
ネットワークエンジニアおよびプロトコル開発者が留意すべき点は以下の3点である。
Identity管理の統合: 今後の標準化活動には、個人のPGP/X.509証明書とDatatrackerアカウントの紐付けが必須となる。
自動ステータス監視: CI/CDパイプラインにおいて、自身の参照しているドラフトの合意状況をACM API経由でリアルタイム取得し、実装の判断基準とすることが可能になる。
ガバナンスの変容: 「声の大きい参加者」による主観的合意形成から、署名された定量的データへの移行に伴い、意思決定ロジックの透明性が劇的に向上する。
今後の標準化ロードマップにおいて、本ドラフトは2025年Q4までに実証実験を完了し、2026年にRFCとしての正式発行を目指している。
