実行コードの優位性――インターネット本来の設計を守るために必要なパッチ

このシリーズにおける Heng.lu の直前の7本のノートは次のとおりです。

ノート52　登録機関の権力が責任から切り離されるとき――なぜ現在の RIR 調整モデルは現状のままでは存続できないのか
ノート53　インターネット番号資源は政治的財産ではない
ノート56　地域インターネットレジストリの厚いガバナンスは一意性を二重収奪へ変える
ノート58　二重収奪から主権の逆転へ――国家はいかにして100米ドルで RIR に主権的統制を失うのか
ノート59　貧困への罰――RIR モデルはいかにして平等と呼びながら貧しい人々に課税するのか
ノート61　実行コードへの裏切り――RIR システムはいかにしてコンセンサスを技術コミュニティに敵対させたのか
ノート62　マンデート・ロンダリング――RIR の幻想から移行アーキテクチャへ

先行する7本の論考は、地域インターネットレジストリの改革計画ではなかった。

それは解剖だった。

それらは、同じ制度病理を異なる層に沿って追跡した。結果から切り離された責任、政治的財産へと改名された番号資源、二重収奪へ変えられた一意性、逆転した主権、平等の名の下で課税された貧困、奉仕すべきネットワークに向けて反転したコンセンサス、そして最後には、事務管理者が主権者のように聞こえ始めるまで洗浄されたマンデートである。この順序が重要なのは、失敗が悪い理事会、悪いレジストリ、訴訟、または不都合な市場イベントではなかったからだ。それは、異なる仮面の下で現れた体系的欠陥だった。CircleID の著者ページはいまやこの流れを明確に示しており、Running-Code Betrayal と Mandate Laundering も含まれている。（circleid.com）

この論考は、RIR をより優れた統治者にすることを目的としない。

現在の登録秩序がなぜ終着点になり得ないのか、そして最も破壊の少ない修復が、インターネット本来の技術設計への補足である理由を説明することが目的だ。

その補足が、実行コードの優位性（Running-Code Primacy）である。

その必要性はもはや理論上のものではない。CircleID の最近のやり取りで、John Curran は現職側の論拠を最も強固な形で示した。彼の主張では、RIR システムの権威は単なる限定的な技術調整の副産物ではなく、ホワイトペーパー、ICANN、ASO、ICP-2、IANA 監督の移行、そして民間部門による継続的な多国間ガバナンスという歴史的連鎖の結果である。RIR システムの権威は、米国政府が推進した民間部門の多国間モデルの中で運用してきた結果だ、と彼は述べる。（circleid.com）

この論拠は、争点を見えるようにする点で有用だ。

問題は、歴史的な委任が存在したかどうかではない。もちろん存在した。問題は、歴史的に委任された調整機能が、自らが統制するその同じ手続きの仕組みを通じて、恒久的な統治マンデートへ拡張できるのかどうかだ。現職側の答えは「できる」である。委任、承認、制度的継続、コミュニティ手続きが、自己更新するマンデートへ変換される。

インターネット本来の技術設計が要求する答えは「できない」だ。

インターネットの原初の伝統は、より狭く、より厳格で、より優れていた。RFC 3935 は IETF の目的を「インターネットをよりよく機能させること」とし、その活動を技術的能力、現実世界での実装、「大まかなコンセンサスと実行コード」に基礎づける。また、IETF があるプロトコルや機能に責任を負わない場合、それを統制しようとはしないと定める。（rfc-editor.org）RFC 7282 は David Clark の古い言葉、「我々は王、大統領、投票を拒む」と「我々が信じるのは、大まかなコンセンサスと実行コード」を繰り返す。（rfc-editor.org）RFC 9592 は反主権的な点をさらに明確にする。IETF はインターネットを指揮、統制、巡回せず、「プロトコル警察」でもない。（rfc-editor.org）

この伝統は、文書が魔法だという意味では決してなかった。文書がシステムを機能させる助けになるときに重要だという意味だった。プロセスが受け入れられたのは、展開に役立ったからだ。会議室が有用なのは、運用上の現実を中心に自らを律したときだけだという意味だった。

レジストリ層はその正統性を借用した。

しかし、その規律を完全には受け入れなかった。

それが欠けているパッチである。

実行コードの優位性とは何か

実行コードの優位性とは、インターネットの調整システムを、稼働中のネットワークが存在することを当初正当化した最小限の技術機能を基準に、厳格に解釈すべきだという意味である。

番号資源層は、稼働中のシステムを守るために存在する。一意性、相互運用性、ルーティングに関係する継続性、安全性の主張、統制の証明、そして独立したネットワークが協働するために必要な最小限の共通セマンティクスである。

政治的権威を製造するために存在するのではない。

商業的道徳を監視するために存在するのではない。

サービスの地理を所有権の証書に変えるために存在するのではない。

メーリングリストを立法府に変えるために存在するのではない。

民間レジストリが内部の政策理論を変えたという理由だけで、すでに運用されているネットワーク資産を消滅させられるようにするために存在するのではない。

レジストリは国家ではない。

データベースの連絡先は、企業の公証済み委任状ではない。

サービス地域は人民ではない。

政策会議は立法府ではない。

レジストリは運用上の現実を記述できる。しかし、それを創造することはできない。

これは保守主義ではない。実行コードの優位性は、展開済みシステムが決して変わってはならないとは言わない。変化に対する制度的権力を、歴史的委任、循環的承認、儀式的手続きによって正当化してはならないと言う。運用者がローカルに検証できる決定論的ルールと、稼働中のシステムでの採用によって正当化されなければならない。

正しい順序は、初期仕様、分散台帳状態、ローカル検証、実行中の実装、自発的採用、互換性セット、そして文書化である。

誤った順序は、政策会議、宣言、主張された義務、コンプライアンス標識、そして強制的な運用執行である。

RIR システムが失敗したのは、ますます後者の順序を選んだからだ。

核心的な修正はこうだ。初期仕様の後に、許可を求めるべき継続的な機関は存在しない。非採用が違反に当たるかを委員会が決めることはない。後からの変更を受け入れないというだけで、レジストリが参加者を無効と宣言することもない。存在するのは、コード、台帳状態、検証、採用、互換性、ローカルな拒否、フォーク、選択的な相互運用だけである。

後からの変更を拒否する運用者は、インターネットを壊すわけではない。より古い互換性セットに留まれる。フォークしてもよい。切断してもよい。互換性のないルールを採用した参加者との相互運用をやめてもよい。しかし、相互に互換性のあるコードを実行し続ける他者の相互運用性を壊すことはできない。

この設計上の直観は、分散台帳を有用にするものと同じだ。通常の状態の有効性を決めるために、恒久的な機関は必要ない。参加者は決定論的ルールに従って状態遷移をローカルに検証する。無効な状態は機関によって罰せられるのではなく、受け入れない参加者によって無視される。

これが番号資源調整に欠けている本質的なパッチである。

設計上の欠陥は最初から存在していた

RIR の初期アーキテクチャは、価値の低い世界を前提としていた。

番号資源は、技術的で、豊富で、事務的で、対立の少ないものに見えた。その世界では、非公式性が効率的に思えた。開かれたメーリングリストは代表性があるように見えた。連絡先に基づく管理で十分に思えた。限定責任の契約は無害に見えた。地域レジストリは単なるアドレス帳に見えた。

IPv4 の希少性がこの前提を破壊した。

IPv4 アドレスは希少となり、移転、融資、リース、資本化が可能なものとなり、訴訟や制裁の対象となり、稼働中のネットワークに組み込まれた。レジストリ層は、事務的なエントリの上に位置することをやめた。生産インフラの上に位置するようになった。資産価値の上に位置するようになった。顧客の継続性、クラウド展開、通信事業、国家接続性、裁判所命令、資本配分の上に位置するようになった。

制度の形は、この新たなリスクに対応するよう調整されなかった。

拡張した。

その結果、技術調整の言葉を使い続けながら、インフラ統治の効果を行使するシステムが生まれた。レジストリのプロセスを中立として扱うよう運用者に求めつつ、レジストリの決定は商業的運命に影響する。参加者を「コミュニティ」と呼ぶ一方で、その結果に耐える人々の多くは、会議室にいる者へ明確な法的代表権を与えたことがない。

NRS は構造的な問題を明快に示している。インターネット番号レジストリは技術調整機関として設計されたが、IPv4 の希少性がアドレスを価値ある資産に変えたとき、レジストリの裁量は経済的権力へ変わった。調整システムが資本を支配すると、集中化は構造的リスクになり、分散化はイデオロギーではなくシステム工学の問題になる。NRS は設計の反対方向も提示する。単一のインターネット、開かれた自律的インフラ、そして人間の関与を最小限にすることを中核とした分散ガバナンスである。（nrs.help）

これが本当の問題だ。調整表が資産への入口に変わった時点で、レジストリ層は適応しなかった。

実行コードの優位性は、その適応である。

これは「より良い RIR」の教義ではない。

RIR 後の規律である。

パッチの三つのルール

構成上の文法は、改訂されたノート64、「インターネット調整システムのための最小初期仕様、局所化された将来決定、自発的採用」である。最小初期仕様、局所化された将来決定、自発的採用。

名称は変えない。論理は正確でなければならない。

最小初期仕様とは、共通層が一意性、相互運用性、統制の証明、共有セキュリティ、セキュリティに関する主張に必要な、決定論的でローカルに検証可能なルールだけを含むことを意味する。ビジネスモデルの選好、価格理論、地域政治の感情、裁量的執行権限、制度的使命の拡張は含まない。

局所化された将来決定は、機関がどの将来決定をローカルにするかを決めるという意味ではない。それでは権威層が再導入される。初期仕様が、あらかじめ制約の仕事を行うという意味である。展開後、通常の将来決定は、コードを実行する参加者の手に残る。参加者は採用、拒否、フォーク、切断、選択的相互運用を選べる。相互に互換性のあるルールを実行し続ける他の参加者の相互運用性を変えることはできない。

自発的採用とは、後からの変更が実装、検証、展開、使用によってのみ現実になることを意味する。公開は現実ではない。勧告は現実ではない。制度的承認は現実ではない。非採用は無効状態を作らない。後からの変更を採用しない参加者は、既存の互換性セットに留まる。別の参加者の決定論的ルールによれば無効な状態を発行する参加者は、ローカルに無視される可能性がある。その効果は制度的な処罰ではなく、互換性の選択である。

この三つのルールは、レジストリの主権を回復させない。

別の名前でそれが再び現れるのを防ぐ。

APNIC：法的構造そのものがリスクだった

APNIC は最初の失敗を示す。最小限の内容が、最初から十分厳格に仕様化されていなかった。

これは行動規範の話ではない。礼儀の話でもない。批判者が既存の機関に十分丁寧だったかという話でもない。

法的構造の話である。

2023年3月、LARUS は法的レビューを公表し、APNIC の統治構造がブリスベンの一企業だけでなく、アジア太平洋地域全体のインターネット・ガバナンスにリスクを生むと警告した。そのレビューは、APNIC の事務総長（Director General）が APNIC を解散し、選出された執行評議会を解任する最終的な法的権限を持つと主張し、緊急の統治改革が必要だと述べた。また、この構造がアジア太平洋地域の10億人を超える利用者にとって、インターネット・ガバナンスの安全性に疑問を投げかけると指摘した。（larus.net）

第1添付資料である ASIC 抄録は、企業としての基盤を示す。APNIC Pty Ltd は、クイーンズランド州で登録された、株式によるオーストラリアの非公開有限会社として登録されていた。Paul Byron Wilson が取締役兼秘書役として記載されていた。株式情報には発行済み普通株式が1株だけ示され、その株式の保有者として Paul Byron Wilson が記載されていた。（larus.net）

これは、地域規模で重要なインターネット調整機能を置く通常の形ではない。

第2添付資料である Peter Felter 博士の法律意見書は、統治上の結論を導く。そこでは、APNIC の会員、選挙、執行評議会、事務総長、事務局という公的構造が、APNIC Pty Ltd の定款第9.3条に基づく特別委員会として説明されている。APNIC Pty Ltd は25年間、取締役、株主、秘書役をすべて兼ねる一人の人物が管理する非公開会社だったと述べる。（larus.net）

この区別は重要だ。

コミュニティ志向の公的機関は、最終的な法的容器ではなかった。民間企業の上に構築された構造だった。

法律意見書は、この区別が重要な理由を説明する。APNIC の定款は、APNIC Pty Ltd の会社定款、ならびに同社とその取締役・役員・会員の権限に従うとされる。この解釈では、APNIC の公的構造は APNIC Pty Ltd の取締役決議によって変更できる可能性がある。意見書は APNIC を、実質的に APNIC Pty Ltd の一部門と説明する。（larus.net）

意見書の最も重大な点は、APNIC が技術的に違法だということではなかった。合法性と正統性は同じではないという点だった。意見書は、信託メカニズムでは問題を解決できないと論じる。執行評議会の権限は、なお特別委員会を設置する取締役決議から派生しているからだ。また APNIC Pty Ltd は株式を持つ民間会社であり、その構造と目的は、公益性を持つ地域レジストリに通常結び付けられる、株式を持たない非営利組織のモデルと一致しないとも指摘する。（larus.net）

これが、最も純粋な形で現れた最初の設計上の失敗である。

地域規模の番号調整システムは、1株だけを持つ民間会社、特別委員会、信託、選出評議会が何らかの形で組み合わさり、アジア太平洋のインターネットレジストリを正当に管理している理由を弁護士に説明してもらう必要がある構造に依存すべきではない。

重要な調整層は、外部から読めるべきだ。

文書の背後にある文書への信頼を必要とすべきではない。

制度に何年も依存した後で、選挙で選ばれた層が法的な最終層ではない可能性を、会員が発見する必要もない。

形式的な権力が別の場所にあるのに、会員による統治に見える形を作るべきではない。

だから最小初期仕様には、制度的信頼ではなく分散型の有効性を含めなければならない。将来の機関により良い統治を求めるためではなく、RIR 後の将来システムは、そもそもその機関を必要とするものであってはならないからだ。

共通層は、民間企業の隠れた統制構造に依存すべきではない。決定論的な検証ルール、統制証明状態、状態遷移ルール、競合ルール、台帳複製、退出経路、フォーク経路、互換性セットを定義すべきだ。APNIC が消滅しても、自らを掌握しても、法的立場を変えても、有効な状態の承認を拒否しても、稼働中のネットワークは、誰がどの番号資源を統制するかを知るために APNIC の承認に依存すべきではない。

レジストリが有効性の源であってはならない。

初期仕様に基づいて検証された分散台帳の状態が源であるべきだ。

ARIN：政策が資産の現実に出会った

ARIN は第2の失敗を示す。法と市場の現実が、レジストリ理論を追い越すことがある。

決定的な出来事は、Nortel と Microsoft の取引だった。Nortel が破産手続きに入ると、666,624個の IPv4 アドレスは手続きの中で価値ある資産となった。アドレスは Microsoft に750万ドルで売却された。ARIN は、アドレスは所有物ではなく、レジストリの政策から自由に売却できないという理論の下で介入した。Industry Canada はその立場を支持した。破産裁判所はそれを退け、Microsoft は後に「legacy」契約に署名した。実務上の結論は明白だった。裁判所と市場が番号資源を資産として扱うようになった時点で、レジストリ政策だけを現実の唯一の源とし続けることはできなかった。（btw.media）

重要な教訓は、ARIN が特に欠陥のある機関だったということではない。

レジストリ層が新しいカテゴリーに入ったということだ。

レジストリは、運用者、裁判所、買い手、売り手、債権者、ネットワークが信頼するから価値を持つ。その依存を否定しても、権威を得られるわけではない。法的、市場的、運用上の現実を十分な精度で反映して初めて、有用であり続けられる。

IPv4 が希少になると、レジストリのプロセスは市場インターフェースになった。移転ルール、必要性評価、承認の遅延、地域制限は、もはや事務上の細部ではない。資産にかかる摩擦になった。現在の公開分析は、1アドレス当たり約18ドルから45ドルで取引される市場を、5つの地域システムが統治する、分断された RIR ルールブックとして描いている。相反するルールは資産を凍結し、合併を遅らせ、アドレスブロックを維持するためだけに別個の企業構造を強いることがある。（btw.media）

これは中立的な調整ではない。

規制責任を負わない規制効果である。

ARIN は、自発的採用がなぜ重要かを示す。レジストリ政策は、関係者が実際に実装し、交渉し、融資し、訴訟し、利用しているものを記述する限りにおいてのみ信頼性を保つ。公開を現実の創造に十分なものとして扱うと危険になる。

現実を拒むレジストリは、主権者にはならない。

時代遅れのデータベースになる。

実行コードの優位性を採用する設計では、教訓はさらに明確だ。裁判所と市場は、価値が存在するかを判断するために既存のレジストリを必要としない。運用者は、ブロックがルーティングされるかを知るために委員会を必要としない。参加者に必要なのは、統制の証明、競合解決、台帳上で見える状態遷移、互換性を可能にする決定論的ルールだ。旧レジストリはビューを公開できる。ソフトウェアクライアントはビューを表示できる。台帳エクスプローラもビューを表示できる。どれも有効性の源ではない。

移行すべきレジストリはない。

尋ねるべきレジストリもない。

参加者が検証し、受け入れ、拒否し、フォークし、相互運用する分散状態だけが存在する。

AFRINIC：レジストリ理論が稼働中の資産を脅かしたとき

AFRINIC は問題を本質まで縮めた中心的事例である。

誤った物語は、問題のある会員が地域レジストリを麻痺させたというものだ。

それは現職側の道徳的物語である。

構造的な物語は異なる。AFRINIC は、商業利用、顧客の地理、リース、会員との関係、内部の政策解釈を、すでに稼働している番号資源を登録抹消する権限として主張しようとした。その主張がなされた時点で、対立は政策会議での意見の相違にとどまれなくなった。民間レジストリが地域的なレトリックと規範上の沈黙を利用し、運用に組み込まれた資産を脅かせるかどうかの試験になった。

事実は、劇的な誇張を必要としない。公開報道は AFRINIC の争いを、IP アドレスをめぐる単純な商業紛争が、アフリカ最大のインターネット・ガバナンスの物語へ変わったものと説明した。また Cloud Innovation はしばしば悪役として描かれてきた一方、後の文書資料は AFRINIC 自身の内部にある破壊的な力と、AFRINIC の代表者が AFRINIC の費用負担で遅らせ、長期化させ、継続させた訴訟を示した。（btw.media）

これは、通常の物語を逆転させるので重要だ。

訴訟が構造的欠陥を作ったのではない。

露呈させたのだ。

民間レジストリが、明示的な許可の欠如を強制的統制の根拠として扱ったとき、関連する欠陥はすでに存在していた。リースは一意性への脅威ではなかった。顧客の地理は重複割当ではなかった。商業利用はルーティングの安全性欠陥ではなかった。レジストリが認めないビジネスモデルは、グローバルな不変条件ではなかった。

それでもレジストリの解釈は、これらを取消しの枠組みに置いた。

ここが、調整が統治へ変わる瞬間である。

報道によれば、AFRINIC は2021年3月、政策違反を主張し会員資格を終了すると脅す書簡を Cloud Innovation に送った。2021年7月、モーリシャス最高裁は AFRINIC が Cloud Innovation の会員資格を取り消すことを禁じ、2021年12月には新たな取消しの試みが阻止された。（btw.media）この一連の出来事は、レジストリが冷静にインターネットを守った物語ではない。レジストリの権威が通常の法に出会った物語だ。

制度崩壊も、レジストリの権力が大きすぎたために起きたのではない。より深い問題は、構造的なロックインだった。レジストリが高価値の稼働資産に対する承認独占を持てば、内部の失敗はインターネット継続性のリスクになる。会員が承認システムから離れられなければ、レジストリの失敗は人質権力になる。

レジストリは、自らのデータ内で証明可能な登録詐欺を是正できる。

レジストリモデルが存在する間、重複割当を防げる。

参加者が依存する間、セキュリティ上の主張を維持できる。

しかし、それらは古いアーキテクチャの過渡的機能だ。

RIR 後のアーキテクチャでは、それらの機能をレジストリは担わない。分散台帳状態、統制証明ルール、競合ルール、ローカルに検証可能な遷移にコード化される。

民間組織がリースを地域への裏切りに変えるべきではない。

顧客の地理を取消しの引き金に変えるべきではない。

商業上の対立を技術的無効性として扱うべきではない。

資産の継続性を許可に変えるべきではない。

AFRINIC は、正しく理解された局所化された将来決定の必要性を示す。将来の商業的決定が「ローカルに属する」と決める中央機関は存在しない。むしろ初期仕様は、こうした決定がそもそも共通層に入らないよう保証すべきだ。リース、顧客の地理、商業利用、価格設定、融資、顧客構成、展開戦略は、一意性、安全性、統制の証明、相互運用性に直接影響しない限り、決定論的な有効性ルールの外に置く。

運用者はアドレスをリースすることで他の運用者の相互運用性を壊せない。

レジストリの歴史的地域の外で顧客にサービスを提供しても壊せない。

レジストリが認めないビジネスモデルを使っても壊せない。

いずれの場合も、運用者は他の参加者が実行する決定論的ルールに適合しない可能性がある。その場合、他者は無効な状態をローカルに拒否する。処罰層はない。コンプライアンス裁判所はない。地域の主権者もいない。

この線引きはイデオロギーではない。

運用上のものだ。

代理人の問題は細部ではない

AFRINIC の選挙をめぐる論争は、第二の欠陥、すなわち代表を可視化した。

NRS は法的に直接的な言葉で代表の基盤を示している。記載された会員は RIR ガバナンス事項について NRS に代表を委ね、記載された各会員は公証済みの委任状（power of attorney）を交付したと主張する。（nrs.help）AFRINIC の選挙紛争中、NRS は会員に対し、自分の名前が投票記録にあるか、または自分が関与しないまま投票が記録されたかを報告するよう求め、そのような事実報告は法的経路で扱うと述べた。（nrs.help）

これは、法的代表とコミュニティのレトリックの違いを示すため重要だ。

RIR システムは、しばしば複数のカテゴリーを一つに押し込める。企業代表、データベース連絡先、技術連絡先、従業員、コンサルタント、代理権を持つ者、政策参加者、メーリングリストの常連参加者である。それらは同じではない。

データベースの連絡先は、登録の管理を助けられる。

公証済みの委任状が有効であれば、その範囲内での代理行為を認めることができる。

政策参加者は専門知識を提供できる。

メーリングリスト参加者は意見を表明できる。

これらのどれも、レジストリの決定の結果に耐えるすべての企業、顧客、国家、債権者、貸し手、買い手、借り手、ネットワークについて、自動的に法的な本人になるわけではない。

この区別は、共通層が薄い間だけ無視できる。レジストリが取消し、移転、リース、市場アクセス、制裁、資産継続性、国家インフラのリスクに対する権力を主張すると、代表は憲法上の問題になる。

会議室はマンデートではない。

メーリングリストは人民ではない。

連絡先登録簿は企業の公証済み委任状ではない。

サービス地域は主権的選挙区ではない。

これは手続きの厳密さの問題ではない。

調整と規範的権威の違いである。

実行コードの優位性システムは、そもそも代表を必要とする決定の数を減らすことで、この問題を避ける。有効性が決定論的でローカルなら、投票すべきことが少なくなる。将来の変更が自発的なら、非採用者が違反状態にあるかどうかを判断する必要はない。状態が分散台帳に表現されていれば、参加者が継続して存在することを既存のレジストリに承認してもらう必要はない。互換性セットが明示されていれば、政策会議に尋ねずに誰と相互運用できるかが分かる。

最良のガバナンス上の問題とは、システム設計によって取り除かれる問題である。

RIPE NCC と LACNIC：クラブとチョークポイント

RIPE NCC と LACNIC は、ある RIR が他より「文明的」だということを示すものではない。RIR モデルが技術的機能を超えて持つ、二つの執行層を示している。クラブとチョークポイントだ。

クラブは誰が尊敬に値するかを決める。チョークポイントは登録上の地位の移動を決める。

RIPE NCC が RIPE 90 における LARUS のスポンサーシップを受け入れなかったことは、クラブ層を明確に示した。会員がスポンサーシップを申し出た。レジストリのエコシステムは、別地域の無関係な紛争を理由に拒否した。これはルーティングの安全性に関する決定ではない。一意性に関する決定でもない。決定論的な検証ルールでもない。空間、可視性、スポンサーシップ、社会的正統性へのアクセスを管理する、私的排除の一種だった。

LACNIC もスポンサーシップを拒否した。地域は違ってもパターンは同じだ。レジストリのクラブが会場、可視性、評判を管理して自らを守る。

これはコミュニティではない。アクセス制御である。

制裁層は、チョークポイントを法的な形で示すため、さらに重大だ。RIPE NCC はオランダに拠点を置くため EU 制裁に従わなければならず、制裁が適用されると RIPE データベースの登録を凍結し、取得と移転を阻止し、一方当事者が十分な文書を提供できない場合には案件を凍結扱いにできると定めている。また銀行要件のため OFAC リストとの照合も行う。（RIPE NCC 制裁透明性）

これは、法律を守る RIPE NCC への批判ではない。オランダの法人はオランダ法と EU 法を守らなければならない。問題はアーキテクチャにある。なぜオランダの民間法人が、複数の国、運用者、法制度の間で番号資源の移動を認める中心点であるべきなのか。

制裁は銀行を拘束できる。オランダの法人を拘束できる。取引をしないと決めた相手方を拘束できる。しかし、他のすべての者にとって技術的有効性の世界的条件になるべきではない。

これが設計上の失敗である。

クラブが批判者を排除できるのと同じ中心性が、法域にレジストリの移動性を凍結させることを可能にする。一方は社会的執行、もう一方は法的執行だ。どちらも、レジストリが有効性の置かれるべきでない場所を占めるから機能する。

これは三つの原則に直接つながる。

最小初期仕様：クラブの尊敬性、スポンサー資格、地域政策、制裁分類、評判は、決して共通層に入れてはならない。共通層には、一意性、統制の証明、競合解決、状態遷移、安全性の決定論的ルールだけを含めるべきだ。

局所化された将来決定：法的リスク、相手方の選択、スポンサーシップ、商業上の信頼、制裁への露出は、それを引き受ける当事者に属する。オランダの法人は取引を拒否できる。銀行は支払いを拒否できる。相手方は関与を拒否できる。そのいずれも、世界的なレジストリの真実になってはならない。

自発的採用：参加者は、コードを実行し、状態を検証し、相互運用相手を選ぶことで相手方を受け入れる。非採用は不正行為ではない。ローカルな拒否は世界的な無効性ではない。クラブによる拒否が有効な状態を消してはならない。制裁義務は影響を受けた当事者を制限すべきであり、番号資源の世界的台帳を書き換えるべきではない。

だから分散台帳アーキテクチャが必要になる。RIR 後のシステムでは、通常の有効性を RIPE NCC、LACNIC、制裁部門、会議委員会、スポンサーシップ事務局が決めない。参加者が状態をローカルに検証する。相手方は自発的に受け入れ、拒否する。フォークは見える。互換性セットは明示される。中央レジストリは真実の源として消える。

解決策は、より良い礼儀ではない。

より透明な制裁キューでもない。

解決策は、クラブとチョークポイントの双方から有効性を取り除くことだ。

分散状態。ローカル検証。相手方の自発的受入れ。有効性の源としてのレジストリなし。

NRO の書簡：上へ逃げる経路

最も重大な証拠は、AFRINIC の行き過ぎの試みではない。

システム全体の集団的な反応である。

2022年、Number Resource Organization はモーリシャス政府に書簡を送った。書簡は NRO を世界の RIR の調整機関と説明し、RIR が各地域の番号資源を管理すると述べた。5つのレジストリは、地域で採用されたルール、または全会一致で採用されたグローバル政策の下で番号資源を管理する機能を果たすと指摘した。（nro.net）

同じ書簡は Cloud Innovation の訴訟を批判し、25件を超える訴訟が提起されたと主張し、AFRINIC の口座を凍結し選挙を停止した裁判所命令に不満を述べ、AFRINIC が国際機関として認められるようモーリシャスに繰り返し要請したと主張した。NRO は政府に対し、AFRINIC の独立性とアフリカのインターネットの安定性を守る措置を取るよう求めた。（nro.net）

これは、この物語全体で最も示唆に富む文書だ。

民間レジストリが通常の裁判所と衝突したとき、システムの反射的な反応はマンデートの範囲を縮小することではなかった。

レジストリのチョークポイントを取り除くことでもなかった。

登録管理と執行を分離することでもなかった。

分散検証を定義することでもなかった。

稼働資産に対する一方的な登録抹消権限が、最初から非正統的だったかを問うことでもなかった。

反射的な対応は、上位へ逃げる道だった。

民間の調整機関が、裁量を求めるときは技術的、正統性を求めるときはコミュニティ的、料金を求めるときは契約的、責任を避けるときは所有者ではない立場を取り、裁判所からの免責を求めるときは準国際的であることはできない。

その組合せは統治ではない。

制度的な「マンデート・ロンダリング」の形である。

RIR が公法上の特権を望むなら、公法上の責任を受け入れなければならない。私法上の柔軟性を望むなら、私法上の訴訟を受け入れなければならない。私的裁量、公共インフラとしての重要性、低い責任、弱い代表、独占的地位、準外交的免責を同時に一貫して要求することはできない。

これが崩壊への道である。

実行コードの優位性はそれを拒否する。

レジストリが法的抵抗に遭ったとき、免責を求めて上へ逃げるべきではない。アーキテクチャは下へ縮み、当初それを正当化した厳格な実行コードの機能へ戻るべきだ。

主権を減らす。

有効性の源としてのレジストリをなくす。

執行を減らす。

分散検証を増やす。

ICP-2 の改訂では不十分だ

現在のシステムは、何かが壊れたことを認識している。

ICANN の RIR ガバナンス文書第2次草案に関するパブリックコメントページは、提案が、新たな RIR を承認するためのルールと基準、既存 RIR の運用上の義務と要件、ならびに承認取消しのルールを定めると述べている。採用されれば ICP-2 に取って代わる。同ページは、RIR システムがインターネット・コミュニティに対してより説明責任を持つよう、NRO が ASO に更新を提案することを求めた後にプロセスが始まったと示している。（icann.org）

継続性の措置として必要かもしれない。

しかし、正統性の理論としては不十分だ。

承認と承認取消しのルールが答えるのは、後の段階の問いだ。レジストリの失敗が、排除すべきほど深刻になったと判断するのは、どの時点か。

より早い問いの方が重要だ。そもそも、なぜレジストリが破局的に失敗できるほどの権力を持つべきなのか。

承認、監査、移行、承認取消しを厳しくするだけの ICP-2 後継は、制度の衛生を改善しながらカテゴリーの誤りを保存する可能性がある。それでも RIR を番号資源調整の第一の主権的形態だと仮定し続ける。

実行コードの優位性は、別の問いの集合を提示する。

RIR が崩壊してもインターネットをどう継続するか。

既存の機関の許可なしに、番号資源の割当をどう検証可能に保つか。

独占的裁量なしに、一意性をどう生き残らせるか。

レジストリが強制執行の道具になるのをどう防ぐか。

真のグローバル不変条件が危険にさらされる場合を除き、商業上の決定を決定論的な有効性の外にどう置くか。

権威あるレジストリなしに、調整をどう利用可能なまま保つか。

恒久的な機関に尋ねず、運用者は通常の状態をどう検証するか。

拒否が違反標識になるのをどう防ぐか。

これらは改革の問いではない。

RIR 後の問いである。

なぜこれが本来の設計へのパッチなのか

問題は、既存のレジストリを好むかどうかではない。

番号資源層が、インターネットを可能にした設計規律、つまり最小限の共通ルール、ローカル検証、自発的採用、実行コードに従い続けるかどうかだ。

実行コードの優位性は、広報戦略でも制度的妥協でもない。本来の設計に暗黙に含まれていた技術的修復である。インターネットが技術的真実の源として王、大統領、投票を拒むよう構築されたのなら、番号資源層は登録プロセス、歴史的委任、コミュニティ劇を通じてそれらの形態を再現できない。

コンセンサスだけでは儀式になり得る。登録層を承認の源として上に置けば、実行コードだけでも従属させられる。欠けているルールは解釈的であり、アーキテクチャ上のものだ。制度的プロセスが稼働中のシステムに必要な最小限の技術機能と衝突するとき、実行コードが優先する。そして後からの変更が提案されたとき、それは検証ルールを実行する参加者の自発的採用によってのみ現実になる。

こうして本来の設計を守るのであり、放棄するのではない。

インターネットが重要だったのは、単一の主権者、官庁、教会、企業、門番から事前許可を得ずに済む最初の世界的通信システムになったからだ。その成果を守る価値があるなら、番号資源層が原則を無効にする例外になってはならない。

王を避けるために作られたシステムは、簿記係が王になろうとすることを許してはならない。

パッチは本来の階層を回復する。まずコード、まず運用者、まず決定論的検証、まず分散状態。移行中に制度が存在するなら、それは非権威的な成果物にすぎず、決して有効性の源ではない。

RIR 後の調整に必要なもの

RIR 後の調整は混乱を意味しない。

現在の RIR 独占よりも、共通層が薄く、客観的で、決定論的で、分散されることを意味する。

移行すべきレジストリはない。

王冠を授ける新しいレジストリもない。

新しい聖職者もいない。

番号資源の状態について、決定論的な検証ルール、統制証明メカニズム、競合処理、互換性セット、状態遷移履歴、参加者によるローカル検証を備えた分散台帳がある。

共通層は、識別子の一意性、統制の証明、移転状態、委任状態、ルーティングに関係する安全性の主張、監査可能性、競合メタデータ、フォークの可視性を維持すべきだ。

運用者層は、商業利用、リース、顧客の地理、ルーティング慣行、融資、相手方の選択、不変条件ではないビジネスルールを管理すべきだ。

採用層が、何が現実になるかを決めるべきだ。調整ルールは、運用者が実装でき、相手方が受け入れられ、市場が信頼でき、裁判所が理解でき、現職の承認を唯一の現実の源にせずに相互運用性が保たれる場合にのみ重要になる。

執行層を状態層と融合してはならない。分散台帳は状態を記録できる。遷移を検証できる。競合を露呈できる。証明を可搬にできる。しかし同時に検察官、裁判官、制裁機関、市場規制者、商業道徳家、資産管理者になるべきではない。

最も重要なのは、可搬性を正しく理解することだ。

分散台帳の世界で、可搬性は一つのレジストリから別のレジストリへ移ることではない。それはレジストリ思考のままだ。移行すべきレジストリはない。保有者の統制証明、状態履歴、移転能力は、既存の機関のデータベース内に閉じ込められていない。それらは、参加者がローカルに検証し、相手方が自発的に受け入れる、共有された検証可能な状態の中に存在する。

それがなければ、各レジストリは阻止点になる。

それがあれば、レジストリは有効性の源ではなくなる。

したがって RIR 後の調整には、4つの設計特性が必要だ。

第一に、決定論的有効性。参加者は、仕様をローカルに適用することで、状態遷移、証明、委任、移転、主張が有効かを知れなければならない。

第二に、互換性セット。参加者が異なる将来ルールを採用するとき、システムは異議を違反として扱うのではなく、互換性の境界を明確に記述しなければならない。

第三に、分散型統制証明。保有者は資源を別のレジストリへ「移す」のではなく、現職の承認なしにどの相手方でも検証できる台帳上の有効状態によって統制を証明しなければならない。

第四に、フォークの可視性。ルールセットが分岐した場合、その分岐は明示的でなければならない。参加者は、どの互換性セットを実行し、どの相手方と関わるかを決める。フォークは参加者を隔離できるが、一方の側に他方を制度的に消去する権限を与えない。

これは、5つのより良い独占を支持する議論ではない。

有効性の源としての独占に反対する議論である。

なぜ失敗経路は予測できるのか

何も変わらなければ、失敗経路は明らかだ。

第一に、より多くの紛争が政策会議から裁判所へ移る。希少な資産は法的精査を引き寄せる。裁判所は、口座の凍結、記録の保全、不正な選挙の阻止、司法管理人の任命、移転の承認、レジストリを代表して行動できる者の決定を求められる。

第二に、国家は RIR を無害な技術団体として扱うことをやめる。アドレスの継続性は、国家接続性、制裁、法執行、通信レジリエンス、クラウドインフラ、経済安全保障に影響する。どの国家も、外国の民間組織を国家通信の継続性に対する、上位にあって問われない点として無期限に受け入れない。

第三に、運用者は可能ならレジストリの権威を迂回する。レジストリが政治的で、安全でなく、代表性を欠き、資産の現実から切り離されれば、運用者は私的契約、訴訟に裏付けられた移転、代替認証、国家承認、または事実上のルーティングの現実に頼る。

第四に、ICANN と NRO の層は集中化へ誘惑される。マンデート自体が縮小されなければ、同じ問題のより密な版が生まれる。

第五に、政府は国有化へ誘惑される。それは予測可能で危険だ。民間レジストリが公的責任なしに準主権的権威を主張すれば、国家は最終的に主権を主張する。結果は分断、報復、対立するレジストリ、ルーティングへの政治圧力になる可能性がある。

インターネットは、パケットが動かなくなったときだけ失敗するのではない。

識別子を誰が使えるかを記述する制度が、パケットを動かす運用者の信頼を失ったときにも失敗する。

分散台帳は、すべての政治問題を解決しない。しかし、より重要なことを行う。通常の有効性の源として恒久的レジストリを取り除く。それにより攻撃面が減る。制度的な人質権力が減る。将来の対立を行政戦争ではなく、互換性の選択に変える。

問いが変わる

古いシステムはこう問う。誰がマンデートを持つのか。

それは間違った問いだ。

より良い問いはこうだ。実行コードは本当に何を必要としているのか。

このルールは一意性を守るか。

相互運用性を維持するか。

決定論的な証拠によって、証明可能な登録詐欺を是正するか。

ルーティングに関係する安全性を守るか。

統制証明の正確性を維持するか。

ローカル検証を可能にするか。

単一の既存の機関への依存を取り除くか。

採用された現実を記述するか、それとも採用されていない義務を宣言するか。

参加者は無効と標識を付けられずに拒否できるか。

参加者は、レジストリに状態を求めずに通常の有効性を検証できるか。

相手方は状態を自発的に受け入れ、拒否できるか。

一方の側が制度によって消去されずにフォークできるか。

答えが実行コードの決定論的な必要性に結び付いていないなら、その権力は共通層に置かれるべきではない。

それが実行コードの優位性である。

議論のために

この提案は議論のためのものだ。最終的な解決策ではない。

次の段階は、番号資源から始めて、インターネット調整システムのための実行コードの優位性を定義する、本格的な Internet-Draft または BCP 型文書であるべきだ。草案は、RIR 独占をどう回復するかを問うべきではない。分散台帳上の状態、決定論的検証、自発的採用、相手方による受入れ、明示的な互換性セットによって、RIR 後の調整をどう構築するかを問うべきだ。

運用者、弁護士、経済学者、プロトコル技術者、ルーティング安全性の専門家、市場参加者、政府、批判者が評価すべきだ。

草案は難しい問いを提起すべきだ。

グローバル不変条件は何か。

どの検証ルールが決定論的か。

どの状態遷移を世界的に見えるようにする必要があるか。

レジストリのどの古い権限が歴史的残余か。

どの決定が運用者に属するか。

そもそも共通層に入れるべきでないため、代表を必要としない決定は何か。

拒否経路は何か。

フォーク経路は何か。

ローカル拒否の経路は何か。

既存のレジストリなしに、保有者はどう統制を証明するか。

レジストリなしに、相手方はどう状態を検証するか。

RIR が崩壊してもインターネットは継続できるか。

既存の機関の許可なしに、番号資源は一意性を保てるか。

恒久的な機関なしに、参加者は通常の状態を検証できるか。

政策プロセスは、実行コードの不変条件と制度的意思を区別できるか。

検証可能な状態を失わずに、古いレジストリ層は消滅できるか。

レジストリは、現実に対する主権者にならずに現実を記述できるか。

関心のある人は LinkedIn を通じて私に連絡できる。本稿を最初の Internet-Draft に、さらにコミュニティが有用と考えるなら RFC または BCP の議論へと発展させることに協力したい真剣な研究者、技術著者、機関、政策専門家は連絡してほしい。LARUS Foundation と私は、この方向の真剣な研究を支援し、資金提供する用意がある。

RIR システムは、実行コードが本当に何を必要とするかを問わなかったため、初期設計で失敗した。

誰が会議室で話せるかを問うた。

次のシステムは、その順序を逆転させなければならない。

これはマンデート・ロンダリングではない。

実行コードへの裏切りではない。

実行コードの優位性。

付録：インターネット調整システムのための最小初期仕様、局所化された将来決定、自発的採用

ノート64

概要

この文書は、システムを実行する参加者の上に継続的な権威を作らずに、共有された技術的基準点を提供するインターネット調整システムの設計パターンを説明する。結び付いた3つの原則、最小初期仕様、局所化された将来決定、自発的採用を定義する。

このモデルでは、初期仕様は一意性、相互運用性、統制の証明、共有セキュリティ、安全性に必要な決定論的でローカルに検証可能なルールだけを定義する。初期仕様の後、将来の変更は中央機関によって承認されない。コードを実行する参加者が採用し、無視し、フォークし、放棄する。

想定する設計パターンは、有効状態の分散台帳、または同等の分散検証可能状態メカニズムであり、レジストリの階層ではない。通常の有効性を決める恒久的なレジストリは存在しない。参加者は状態をローカルに検証し、相手方を自発的に受け入れ、どの互換性セットを実行するかを決める。

非採用は違反ではない。後からの変更を採用しない参加者は、既存の互換性セットに留まる。別の参加者が受け入れた決定論的ルールによれば無効な状態を発行する参加者は、その参加者からローカルに無視される可能性がある。その効果は、制度的処罰ではなく、互換性の選択、フォーク、隔離、選択的相互運用である。

この文書はネットワークプロトコル（wire protocol）を定義しない。恒久的な統治機関になってはならないプロトコル、識別子システム、分散台帳、調整メカニズムの設計に関する現行ベストプラクティス（BCP）を仕様化する。

1. はじめに

多くのインターネットシステムは、限定された技術的目的から始まる。共通の基準点、識別子空間、検証ルール、台帳状態、共有された統制証明登録を通じて、独立した主体が相互運用できるようにすることだ。時間がたつと、こうしたシステムは初期の相互運用性には不要だった権威を蓄積しがちである。

通常、これは3段階で起こる。

第一に、将来の問いが技術的に必要になる前に、基礎層へ組み込まれる。

第二に、自らのシステムを実行する参加者が決めるべき決定が、恒久的機関による承認、解釈、地位決定に依存するようになる。

第三に、参加者が稼働中のシステムで変更を採用していない場合でさえ、公開、登録、勧告、手続き上の承認が運用上の義務を作るのに十分なものとして扱われる。

結果は脆弱なシステムだ。技術的基準層が統治層になる。レジストリが統制点になる。調整の成果物が将来の統制源になる。

この文書は異なる設計規律を提案する。

最小初期仕様：基本的な相互運用性、一意性、統制証明、共有セキュリティ、安全性に必要な決定論的な共通ルールだけを定義する。

局所化された将来決定：初期仕様の後、将来の決定をコードを実行する参加者に留める。参加者は採用、拒否、フォーク、切断、選択的相互運用を選べる。相互に互換性のあるルールを実行し続ける他の参加者の相互運用性を変えることはできない。

自発的採用：後からの変更を、コードを実行する参加者による実装、運用、検証、採用によってのみ現実にする。

これらの原則は関係している。初期から指定しすぎるシステムは、将来の統制を共通層に前倒しする。継続的な承認層を維持するシステムは、展開後に権威を再び蓄積させる。公開を現実として扱うシステムは、文書をマンデートに変える。

設計上の直観は単純だ。有効性は、共有状態に対して参加者がローカルに検証できる決定論的ルールで決めるべきだ。参加者は後からの変更を採用したり拒否したりできる。また、フォーク、切断、選択的な相互運用も選べる。せいぜい互換性セットから離脱できるだけだ。相互に互換性のあるルールを実行し続ける他の参加者の相互運用性を、変更拒否によって壊すことはできない。

これは分散台帳設計の一般的な教訓である。コンセンサスルールは、検証コードを実行し、どの状態を受け入れるかを決める参加者によって適用される。参加者の上に置かれた機関によって適用されるのではない。

2. 適用範囲

この文書は、インターネット調整システムに適用される。識別子システム、名前と番号の枠組み、プロトコル拡張メカニズム、統制証明システム、可搬性システム、分散台帳、その他、独立した主体が共通の技術的基準点に依存するアーキテクチャを含むが、これらに限られない。

この文書は共通ルールに反対するものではない。共通ルールは決定論的で、最小限で、ローカルに検証可能で、システムが機能するために本当に必要な範囲に限るべきだと主張する。

この文書は特定の分散台帳実装を要求しない。設計上の性質を要求する。参加者は、恒久的な権威に許可や地位を求めず、初期仕様を共有または複製可能な状態にローカルに適用することで有効性を決定できなければならない。

3. 表記と定義

3.1. 要件言語

この文書で大文字で記された要件用語は、BCP 14、特に RFC 2119 と RFC 8174 で定義された意味に解釈しなければならない。

3.2. 用語

初期仕様：
システムの最初の展開に必要なルール、データ構造、形式、不変条件、検証手順、状態遷移ルール、競合ルールの集合。

共通層（Common Layer）：
独立した参加者が相互運用するために必要な共有ルールまたは基準構造の最小集合。共通層は機関ではない。参加者が実装し検証する技術的実体である。

分散台帳（Distributed Ledger）：
恒久的なレジストリ、委員会、その他の権威に依存せず、参加者が通常の有効性を検証できるようにする、状態遷移の複製された、または別の形で分散された記録。この用語は特定のコンセンサスアルゴリズムや実装を要求しない。

決定論的検証ルール（Deterministic Validation Rule）：
指定されたルールセットの下で、状態、記録、遷移、主張、メッセージが有効かどうかを、ローカルな計算または検証によって参加者が決定できるルール。

グローバル不変条件（Global Invariant）：
一意性、基本的な相互運用性、統制証明の完全性、共有セキュリティ、安全性を維持するため、互換性セット内で共通に保たれるべき性質。

参加者（Participant）：
システムを実行、検証、展開するか、またはシステムに依存する運用者、実装、ノード、ネットワーク、組織、その他の主体。

互換性セット（Compatibility Set）：
実装された検証ルールによって相互運用できる参加者のグループ。後からの変更を一部の参加者が採用し、他が採用しない場合、その変更によって新しい互換性セットが生まれることがある。

採用（Adoption）：
システムを実行する参加者による、実際の実装、展開、検証、利用。

相手方の受入れ（Counterparty Acceptance）：
参加者が、自ら実行する検証ルールの下で、別の参加者の状態を受け入れ、取引し、相互運用し、または信頼するという自発的な決定。

非採用（Non-Adoption）：
参加者が提案された変更を実装または使用しないという決定。非採用は無効状態を作らない。その変更が作った互換性セットに参加していないことを意味するだけである。

ローカル拒否（Local Rejection）：
参加者が、自ら実行する検証ルールによれば無効または互換性がない状態、メッセージ、記録、遷移を無視もしくは拒否するか、またはそれらとの相互運用を行わないとローカルに決めること。

フォーク（Fork）：
二つ以上の互換性セットを生む、検証ルールまたは運用慣行の分岐。

調整成果物（Coordination Artifact）：
参加者の調整を助ける文書、勧告、実装ノート、プロファイル、参照実装、台帳エクスプローラ、複製物、その他の成果物。参加者が稼働中のシステムで採用しない限り、調整成果物は拘束力のある運用上の現実を作らない。

4. 問題設定

設計者は、基礎層に書き込みすぎるか、恒久的な機関に将来の問題の解釈を委ねることで、将来の不確実性を減らそうとすることが多い。これは慎重に見える。危険であることが多い。

基礎層の過剰仕様には、3つのコストがある。

第一に、将来の決定を、変更が難しく、捕捉の効果が大きい共通層へ移す。

第二に、技術的有効性と制度的承認の間に曖昧さを作る。

第三に、レジストリを維持し、文書を公開し、参加者を招集する機関が、それらの行為を将来の現実に対する権威として扱うよう促す。

同じ問題は展開後にも現れる。システムが変更を承認し、状態を決定し、通常の運用を解釈する恒久的機関を必要とするなら、システムは基礎の後に統制層を作っている。その層は管理として始まるかもしれない。統治になり得る。そしてチョークポイントになり得る。

この文書の設計目標は、より良い制度的裁量ではない。その裁量の必要性を避けることだ。

適切に設計されたインターネット調整システムは、最初から決定論的でローカルに検証可能な有効性ルールを定義し、有効状態を分散または複製可能な形で表現し、不変ではない決定を共通層の外に置き、後からの変更が稼働中のシステムで参加者が自発的に採用したときにのみ現実になるようにすべきだ。

5. 原則1：最小初期仕様

5.1. 宣言

初期仕様は、基本的な相互運用性、一意性、統制証明、共有セキュリティ、安全性に必要な最小限の共通決定論的ルールだけを定義すべきである（SHOULD）。

5.2. 要件

この原則を用いる設計は、次のことを行う。

• グローバル不変条件を明示的に特定しなければならない（MUST）。
• 各グローバル不変条件について、決定論的な検証ルールを定義しなければならない（MUST）。
• 有効な状態の表現、複製、検証、更新の方法を定義しなければならない（MUST）。
• 宣言されたグローバル不変条件の維持にも初期展開にも必要のないルールを、初期仕様に含めてはならない（MUST NOT）。
• 検証ルールを、政策上の選好、商業契約、制度上の役割、ガバナンス上の目標、裁量的判断から分離しなければならない（MUST）。
• 参加者が機関、レジストリ、委員会、政策機関、その他の権威に情報を求めず、通常の有効性をローカルに検証できるようにしなければならない（MUST）。
• ローカル検証に必要なデータ構造、署名、証明、状態遷移ルール、競合ルール、その他のメカニズムを定義すべきである（SHOULD）。
• 将来の多様化が予測される場合は、拡張シグナリング、バージョン管理、互換性の表示、フォークの識別を定義すべきである（SHOULD）。
• 必要な調整成果物が可搬で、監査可能で、再現可能で、置換可能であることを保証しなければならない（MUST）。
• 主観的な価値判断よりも、機械で検証可能な客観的条件を優先すべきである（SHOULD）。
• 有効な状態を把握し、登録し、利用するための唯一の手段を、将来の制度的承認にしてはならない（MUST NOT）。

5.3. 設計上の含意

最小初期仕様は、曖昧な仕様を意味しない。共通でなければならないものだけを厳格に仕様化することを意味する。

システムが機能するには、なお十分な共通構造が必要だ。規律とは、次を区別することである。

• 一意性、相互運用性、統制証明、共有セキュリティ、安全性のために共通でなければならないもの。
• 運用者の選好、商慣行、相手方の選択、展開時期、後からの採用判断に属するため、共通層の外に置けるもの。

グローバル不変条件と決定論的検証ルールを明確に表現できない設計は、裁量を過剰に仕様化する一方で、検証可能な内容を十分に仕様化していないとみなすべきだ。

6. 原則2：局所化された将来決定

6.1. 宣言

初期仕様の後、将来決定はコードを実行する参加者にローカルなままであるべきだ（SHOULD）。将来決定は、それを採用する参加者の互換性セットに対してのみ有効になる。承認のために恒久的な権威は必要なく、非採用は無効状態を作らない。

6.2. 要件

この原則を用いる設計は、次のことを行う。

• 参加者が属する互換性セットの決定論的な検証ルールを変えない決定について、既存の機関、レジストリ、委員会、評議会、政策機関、その他の権威から許可を得るよう参加者に要求してはならない（MUST NOT）。
• 後からの変更を運用上の現実にするために、その機関の承認が唯一の手段となるような恒久的機関を設けてはならない（MUST NOT）。
• 初期仕様に基づく有効性と、後から任意に行われる変更との互換性を区別しなければならない（MUST）。
• 後からの変更を採用しないことを、無効性として扱ってはならない（MUST NOT）。
• 後からの変更を採用しない参加者が、既存の互換性セットに留まれるようにしなければならない（MUST）。
• 参加者が新しい検証ルールまたは運用プロファイルを採用することで、新しい互換性セットに参加できるようにしなければならない（MUST）。
• 参加者が実行する検証ルールに照らして無効または互換性のない状態、記録、遷移、メッセージを、ローカルに拒否できるようにしなければならない（MUST）。
• 参加者が受け入れる検証ルールと互換性セットに基づき、相手方を自発的に選べるようにしなければならない（MUST）。
• 後からの変更を拒否しただけで参加者を無効と宣言する権限を、機関、レジストリ、委員会、政策機関、その他の主体に与えてはならない（MUST NOT）。
• 参加者が自分の実行するルールと相互運用できる相手を理解できるよう、フォーク、バージョン、プロファイル、互換性セットを明示すべきである（SHOULD）。
• 既存のレジストリが、有効な参加者間の相互運用の継続を妨げることのできる設計を避けるべきである（SHOULD）。

6.3. 設計上の含意

局所化された将来決定は、中央権威が将来決定をローカルな主体へ割り当てることを意味しない。初期仕様の後、通常の将来決定がそのような割当を必要としないようシステムを設計することを意味する。

初期仕様が、制約の仕事を前もって行う。一意性、相互運用性、統制証明、共有セキュリティ、安全性に必要な最小限の不変条件を定義する。それ以外は共通層の外に残る。

将来の変更は中央で承認されない。コードを実行する参加者が採用、無視、フォーク、放棄する。

変更を拒否する参加者は、その変更が作った互換性セットの外に留まれる。他者から切断してもよい。以前の互換性セットを続けてもよい。フォークしてもよい。選択的に相互運用してもよい。しかし、相互に互換性のあるルールを実行し続ける他の参加者の相互運用性を壊すことはできない。

無効または互換性のない状態の効果は、処罰ではなくローカル拒否だ。誰かが参加者を違反状態にあると判断する必要はない。互換性のある検証ルールを実行する参加者は、無効または互換性のない状態を単に受け入れない。

7. 原則3：自発的採用

7.1. 宣言

インターネット調整システムの変更は、公開または宣言だけでなく、実装、検証、展開、相手方による受入れ、参加者による採用を通じて、運用上の現実になるべきである（SHOULD）。

7.2. 要件

この原則を用いる設計は、次のことを行う。

• 公開、勧告、会議での承認、手続き上の承認だけで普遍的な運用義務が生じるとみなしてはならない（MUST NOT）。
• 新しいルール、拡張、プロファイル、手順を、実行すると決めた参加者が段階的に展開できるようにしなければならない（MUST）。
• 参加者が自身の互換性セットの決定論的な状態遷移ルールを満たしている限り、後からの変更を拒否しても無効扱いされないようにしなければならない（MUST）。
• 初期仕様が継続を許す場合、参加者が以前の互換性セットを使い続けられるようにしなければならない（MUST）。
• ある互換性セットで運用する参加者が、ルールに互換性のない別の互換性セットの状態を、ローカルに拒否または無視できるようにしなければならない（MUST）。
• バージョンシグナリング、互換性の表示、移行ガイド、テストベクトルを含め、重要な変更の採用経路を定義すべきである（SHOULD）。
• 変更を採用しない参加者が運用を続け、互換性セットを識別し、曖昧な相互運用を避ける方法を含め、重要な変更の拒否経路を定義すべきである（SHOULD）。
• 実行不可能なほど高い移行コストを生じさせずに、必要な調整成果物を放棄、複製、再実装、置換できるようにしなければならない（MUST）。
• レジストリ、勧告、調整成果物は、採用されていない将来の状態を既存の現実として宣言しようとするのではなく、実際に採用された状態を記述すべきである（SHOULD）。
• 既存の機関による事前承認を、変更を現実にするための唯一の手段とするシステムを設計してはならない（MUST NOT）。

7.3. 設計上の含意

自発的採用は、変更が有用で、許容可能で、現実の展開と互換性があるかどうかの運用上の試験である。

提案は現実ではない。勧告は現実ではない。文書は現実ではない。参加者が変更を実装、検証、展開し、相手方を受け入れ、依存したときに現実が現れる。

非採用は違反状態を作らない。変更が作った互換性セットに参加していないという事実を作るだけだ。

これは標準化プロセス、文書、実装ノート、エクスプローラ、複製、レビューをなくすものではない。範囲を制限する。参加者の調整を助けられる。参照資料を公開できる。採用を記述できる。勧告できる。しかし、宣言だけで、実行していない参加者に採用されていない将来の現実を拘束的にすることはできない。

8. 3原則の関係

3原則は互いに強化し合い、単独では有効ではない。

最小初期仕様は、共通層が裁量的権威ではなく決定論的検証ルールを含むことを保証する。

局所化された将来決定は、将来の決定が中央の承認層に再捕捉されず、コードを実行する参加者に留まることを保証する。

自発的採用は、後からの変更が実装、検証、相手方の受入れ、利用との接触を生き残らなければならないことを保証する。

1つまたは2つだけ採用するシステムは、別の手段で同じ集中化を再現する可能性がある。

局所化された将来決定のない最小初期仕様は、展開後に権威を蓄積させる可能性がある。
最小初期仕様のない局所化された将来決定は、参加者がローカルに有効性を決定できないため、曖昧さを生む可能性がある。
決定論的検証のない自発的採用は、互換性のある変化と無効な状態を区別できないため、混乱を生む可能性がある。
分散状態のない決定論的検証は、参加者を特権的なレジストリに依存させ続ける可能性がある。
フォークの可視性のない分散状態は、運用上の失敗まで異議を隠す可能性がある。
相手方の自発的受入れのない分散状態は、別のインターフェースを通じて強制を再現する可能性がある。

原則を合わせると、共通層は薄く、有効性はローカルに検証可能で、将来の変更は自発的で、状態は分散され、通常の運用を決める恒久的機関が不要なシステムになる。

9. 推奨される設計パターン

9.1. 決定論的な分散共通層

共通層は次に限るべきである （SHOULD）。

• 安定した識別子のセマンティクス。
• 決定論的な有効性ルール。
• 一意性を保つために必要な競合解決ルール。
• 統制証明メカニズム。
• 状態遷移ルール。
• ネットワークまたはプロトコルレベルの相互運用性要件。
• 共有された安全性の不変条件。
• 可搬で監査可能な状態形式。
• 分散または複製された状態の可視性。
• 拡張シグナリングと互換性セット識別。

共通層は次を含めるべきではない （SHOULD NOT）。

• ビジネスモデルのルール。
• 価格ルール。
• 地域の政治的選好。
• 技術的不変条件と関係のない適格性イデオロギー。
• 裁量的な執行権限。
• 主観的なメリット評価。
• 制度的使命の拡張。
• 既存の機関の権威を保つことを主な機能とするいかなるルール。

9.2. 運用者の意思決定領域

次の事項は、宣言されたグローバル不変条件を直接変更しない限り、共通層の外に残すべきである（SHOULD）。

• 展開時期。
• 商業利用。
• 顧客の地理。
• リース、融資、移転の契約。
• 適格性に関するローカルな選好。
• 運用上の順序付け。
• 共有有効性に必要とされないルーティング慣行。
• ビジネスモデル。
• 組織構造。
• 自発的移行の時期。
• 任意のプロファイルまたは拡張。
• 相手方の選択。

参加者は、これらの領域で異なる決定を採用できる（MAY）。その決定は、異なる互換性セット、商業関係、ピアリング契約、運用コミュニティを生む可能性がある。互換性セット内の決定論的検証ルールに違反しない限り、無効性を生まない。

9.3. 採用サイクル

可能な場合、システムの重要な変更について推奨される順序は次のとおりである。

• 提案。
• 実装。
• テストベクトルまたは決定論的検証方法。
• 希望する参加者による限定展開。
• 相互運用性と安全性の効果の観察。
• 互換性セットの標識付け。
• 採用された現実を記述する文書または勧告。

調整成果物は、採用を先取りしようとするのではなく、採用に続くべきである（SHOULD）。

9.4. フォーク、ローカル拒否、相手方の受入れ

適合する設計は、フォーク、ローカル拒否、相手方の受入れを失敗ではなく通常の設計要件として扱うべきである（SHOULD）。

システムは、参加者が次のことを行える方法を定義するべきである（SHOULD）。

• 以前の互換性セットを継続する。
• 新しい互換性セットを採用する。
• 別の互換性セットへフォークする。
• 既存のレジストリに依存せず状態を検証する。
• 相手方を自発的に受け入れる。
• 無効または互換性のない状態をローカルに拒否する。
• 互換性が許す場合に選択的に相互運用する。

有効な運用を破壊せずにフォーク、ローカル検証、選択的相互運用ができないシステムは、登録機能の中に統治権力を隠している可能性が高い。

10. 適用可能性と限界

この設計パターンは、特に次の場合に適用できる。

• システムが複数主体・複数法域にまたがる。
• 独立した展開が重要である。
• 調整層が薄いまま保たれることを意図している。
• 将来の変化が予想されるが、詳細を予測できない。
• ロックインや依存が統治リスクを生む。
• 有効性を決定論的またはローカルに検証可能にできる。
• 分散状態が制度的捕捉のリスクを減らせる。

次の場合には、直接の適用可能性が低いことがある。

• 単一の管理領域を想定したアーキテクチャである。
• 強いリアルタイム結合が常時の均一な挙動を要求する。
• 生命に関わる安全性の考慮が即時の世界的な均一性を要求する。
• 実務的な機構によっても有効性をローカルに検証できない。

このような場合でも、設計者は引き続き共通層を最小化し、可能な限り将来の裁量的統制を避けるべきである（SHOULD）。

11. 非目標

この文書は次のことを行わない。

• あらゆる調整を禁止する。
• 特定の分散台帳実装を要求する。
• コンセンサスを保証する。
• 政治的中立性を保証する。
• すべての参加者に、後からの変更をすべて採用するよう要求する。
• 採用拒否を無効性として扱う。
• 互換性を主張して互換性のないローカルな行動を正当化する。
• 安全性にとって重要な共通ルールの必要性をなくす。

12. 安全性に関する考慮

より薄い調整層は、捕捉のリスクを減らし、制度上のエラーの影響範囲を小さくし、置換能力を高める可能性がある。しかし、より大きなローカル裁量と分散状態は、一貫しない安全性の姿勢、劣化経路、分断圧力、曖昧な互換性主張、安全でないフォーク、台帳状態をめぐる紛争、証明の偽造の試みを生む可能性もある。

したがって、この文書を適用する設計者は、安全性の不変条件を明示的に仕様化しなければならない（MUST）。特に次のとおりである。

• 共有有効性に必要な認証・認可要件は、決定論的でローカルに検証可能でなければならない（MUST）。
• 統制証明メカニズムは、偽造、リプレイ、不正な移転に耐えなければならない（MUST）。
• 安全性に影響する場合、バージョン交渉と拡張処理は、気付かれないままのダウングレードを避けなければならない（MUST）。
• 拒否、フォーク、置換の経路は、濫用とサービス拒否のリスクについて分析しなければならない（MUST）。
• 互換性標識は、互換性のないルールセット間の偶発的な相互運用を避けるほど明確であるべきである（SHOULD）。
• 分散状態は、一貫しないビューを検出できるよう監査可能で再現可能であるべきである（SHOULD）。
• ローカルな変化が、満たしていないルールセットとの互換性を偽って宣言できてはならない（MUST NOT）。

安全性の例外が存在することは、一般的な許可層を正当化しない。宣言されたグローバル不変条件を守るために必要な決定論的な安全性ルールだけを正当化する。

13. IANA に関する考慮

この文書は IANA による措置を必要としない。

14. 参考文献

14.1. 規範的参考文献

• RFC 2119 — Bradner, S., RFC で要件レベルを示すために使用するキーワード、BCP 14、RFC 2119。
• RFC 8174 — Leiba, B., RFC 2119 のキーワードにおける大文字と小文字の曖昧性、BCP 14、RFC 8174。

14.2. 情報提供用参考文献

• RFC 6709 — Carpenter, B. および B. Aboba, プロトコル拡張の設計上の考慮、RFC 6709。
• RFC 7282 — Resnick, P., IETF におけるコンセンサスとハミングについて、RFC 7282。

付録A. 設計チェックリスト

この文書への適合を主張する設計は、次の問いに明確に答えられるべきである（SHOULD）。

• グローバル不変条件は何か。
• どの決定論的検証ルールが、グローバル不変条件を保つのか。
• 初期展開に厳密に必要な初期仕様のルールは何か。
• 有効状態はどのように表現され、検証されるか。
• 状態は分散、複製、または別の方法で独立に検証可能か。
• どの将来の問題を、意図的に共通層の外に置くか。
• 参加者は、属する互換性セットを変えずにどの将来決定を行えるか。
• 参加者は後からの変更をどう採用するか。
• 参加者は、無効状態を割り当てられずに後からの変更をどう拒否するか。
• 互換性セットはどう標識付けされ、発見されるか。
• 参加者が実行するルールに基づき状態が無効または互換性を持たない場合、ローカル拒否はどう機能するか。
• フォーク経路は何か。
• 既存のレジストリなしに、保有者はどう統制を証明するか。
• レジストリなしに、相手方はどう状態を検証するか。
• 参加者は既存のレジストリに依存せず通常の有効性を検証できるか。
• レジストリと調整成果物は採用された現実を記述するか、それとも採用されていない将来の現実を存在すると宣言しようとするか。
• システムは共通層に組み込まれた決定の数を最小化したか。
• システムは参加者の通常状態を決める恒久的権威を避けたか。
• 参加者は相手方を自発的に受け入れ、拒否できるか。
• 既存のレジストリがすべて消滅しても、システムは継続できるか。

著者連絡先

Lu
[TBD]