稼働コード優先原則――インターネット本来の設計を守るために必要なパッチ
レジストリ層でインターネット本来の設計を取り戻すには、どんなひとつの修正が必要なのか？
各参加者が自分で確かめられる。Lu Hengの提案では、有効性の根拠は常設レジストリの許可ではなく、各参加者が手元で検証できる規則と実際の利用にある。
Heng.luでこの連作に先行する7本の論考は、次のとおりである。
- ノート52：レジストリの権力が法的責任から切り離されるとき――現在のRIR調整モデルが今の形では存続できない理由
- ノート53：インターネット番号資源は政治的な所有物ではない
- ノート56：地域インターネットレジストリの肥大化した統治が、一意性を二重の収奪に変える
- ノート58：二重の収奪から主権の逆転へ――国家はなぜ100米ドルで主権的な統制をRIRに奪われるのか
- ノート59：貧困への罰――RIRモデルは「平等」を掲げながら、いかに貧しい人々に課税するのか
- ノート61：稼働コードへの裏切り――RIR制度はいかに合意を技術コミュニティに敵対するものに変えたか
- ノート62：権限のロンダリング――RIRという幻想から移行のアーキテクチャへ
これまでの7本の論考は、地域インターネットレジストリを改革するための計画ではなかった。
それは解剖だった。
同じ制度的病理を、異なる層から追ってきた。行為の帰結から切り離された法的責任。政治的な所有物へと看板を掛け替えられた番号資源。二重の収奪に変えられた一意性。逆転させられた主権。平等の名の下で貧困に課された税。本来支えるべきネットワークに敵対するものへと変えられた合意。そして最後には、事務員が主権者のように語り始めるまで繰り返された、権限のロンダリングである。この順序には意味がある。失敗の原因は、ひとつの悪い理事会、ひとつの悪いレジストリ、ひとつの訴訟、あるいはひとつの都合の悪い市場の出来事ではなかった。異なる姿で現れる、システムそのものの欠陥だった。現在、CircleIDの著者ページでも、稼働コードへの裏切りと権限のロンダリングを含む、この連作をはっきり確認できる。（circleid.com）
本稿の目的は、RIRをよりよい統治者にすることではない。
現在のレジストリ秩序を最終到達点にしてはならない理由と、最も混乱の少ない修復が、インターネット本来の技術設計を補うものになる理由を説明することだ。
その補完こそ、稼働コード優先原則である。
その必要性は、もはや理論上の話ではない。最近の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後のための規律である。
パッチを構成する3つの原則
建設的な設計の骨格は、改訂版のノート64：インターネット調整システムにおける初期仕様の最小化、将来の意思決定の局所化、自発的な採用に示されている。初期仕様の最小化、将来の意思決定の局所化、そして自発的な採用である。
名称は変えない。その論理は正確でなければならない。
初期仕様の最小化とは、共通層に含めるものを、一意性、相互運用性、支配権の証明、共通の安全性とセキュリティのために必要な、決定論的かつ各参加者が手元で検証できる規則だけにすることだ。ビジネスモデルの好み、価格設定の理論、地域の政治的感情、裁量による執行権限、あるいは機関の使命の拡張は含めない。
将来の意思決定の局所化とは、どの将来の判断を各参加者に委ねるかを、機関が決めることではない。それでは、すでに権威の層を再導入してしまう。初期仕様があらかじめ範囲を限定するという意味だ。導入後の通常の選択は、コードを動かす参加者の手元に残る。参加者は、採用、拒否、フォーク、切断、選択的な相互運用を選べる。互いに互換性のある規則を動かし続ける他の参加者の相互運用性を、どの参加者も変更することはできない。
自発的な採用とは、後の変更が現実になるのは、実装、検証、導入、利用を通じてのみだということだ。公表は現実ではない。勧告は現実ではない。既存機関による承認は現実ではない。不採用によって無効という地位が生じることはない。後の変更を採用しない参加者は、それまでの互換性集合にとどまる。他の参加者の決定論的な規則では無効となる状態を出力する参加者は、その相手からローカルに無視されることがある。その効果は互換性の選択であり、機関による処罰ではない。
この3つの原則は、レジストリの主権を立て直すものではない。
別の名前で再び現れることを防ぐものだ。
APNIC：リスクは法的構造にあった
APNICは、最初の失敗を示している。出発点で、最小限の範囲が十分に厳格に定められていなかった。
これは行動規範の話ではない。礼儀の話でもない。批判者が既存機関に対して十分に丁寧だったかどうかという話でもない。
法的構造の話である。
2023年3月、LARUSは法的検討を公表した。APNICの統治構造が生み出すリスクは、ブリスベンの一企業にとどまらず、アジア太平洋地域全体のインターネット・ガバナンスに及ぶという警告だった。その検討は、APNICの事務局長がAPNICを閉鎖し、選挙で選ばれた執行評議会を解任する最終的な法的権限を持っており、統治制度の緊急改正が必要だと述べていた。また、この構造は、アジア太平洋地域の10億人を超えるインターネット利用者に関わるガバナンスの安全性に疑問を投げかけるとも述べていた。（larus.net）
最初の添付資料である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の構造は、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アドレスは、破産手続きにおける価値ある資産になった。そのアドレスは750万ドルでMicrosoftに売却された。ARINは、アドレスは財産ではなく、レジストリのポリシーに拘束されない形で売却することはできない、という理論に基づいて介入した。カナダ産業省も、その見方を支持した。破産裁判所はそれを退けた。その後、Microsoftはレガシー契約を締結した。そして実務上の結論は明白だった。裁判所と市場が番号資源を資産として扱うようになれば、レジストリのポリシーだけを現実の源泉に据え続けることはできない。（btw.media）
重要な教訓は、ARINだけが特別に欠陥を抱えていたということではない。
レジストリ層が、新しい種類の存在になっていたということだ。
レジストリの記録に価値があるのは、運用者、裁判所、買い手、売り手、債権者、ネットワークがそれを頼りにするからだ。その依存を否定しても、記録に権威が生まれるわけではない。法、市場、運用の現実を、信頼に足る精度で追跡してこそ、役に立ち続ける。
IPv4が希少になると、レジストリの手続きは市場との接点になった。移転規則、必要性の審査、承認の遅れ、地域的制約は、もはや事務上の細部ではなくなった。資産を動かす際の摩擦になった。現在公表されている分析は、5つの地域制度が、アドレス1個当たりおおむね18～45ドルで取引される市場を統治する、分断されたRIR規則体系を描いている。規則の不一致によって、資産が動かせなくなり、合併が遅れ、番号ブロックを保有するだけのために別の法人構造を設けざるをえなくなることがある。（btw.media）
これは中立的な調整ではない。
規制者としての説明責任を伴わない、規制と同じ効果である。
ARINは、自発的な採用が重要である理由を示している。レジストリのポリシーが信頼に値するのは、当事者が実際に実装し、取引し、資金を調達し、訴訟で争い、頼りにしているものを記述している間だけだ。公表するだけで現実を作り出せると扱われたとき、それは危険になる。
現実を拒むレジストリは、主権者になるのではない。
更新されないデータベースになる。
稼働コード優先原則に基づく設計では、この教訓はさらに鮮明になる。裁判所と市場は、価値が存在するかどうかを決めるために、既存レジストリを必要としない。運用者は、あるブロックがルーティングされるかどうかを知るために、委員会を必要としない。参加者に必要なのは、支配権の証明、競合の解決、台帳上で確認できる状態遷移、互換性を可能にする決定論的な規則だ。古いレジストリは、ひとつの見方を公表してもよい。ソフトウェアのクライアントは、ひとつの見方を表示してもよい。台帳エクスプローラーも、ひとつの見方を表示してもよい。いずれも、有効性の源泉ではない。
移る先のレジストリはない。
尋ねるべきレジストリもない。
あるのは、参加者が検証し、受け入れ、拒否し、そこからフォークし、あるいは相互運用する、分散した状態だけだ。
AFRINIC：レジストリの理論が稼働中の資産を脅かしたとき
AFRINICが中心的な事例であるのは、問題をその本質だけにまで削ぎ落としたからだ。
厄介な会員が地域レジストリを麻痺させた、という語りは誤っている。
それは既存制度側の勧善懲悪劇だ。
構造に目を向ければ、別の姿が見える。AFRINICは、商業利用、顧客の所在地、リース、会員関係、内部ポリシーの解釈を、すでに稼働する番号資源の登録を抹消できるという権限の主張に変えようとした。その主張がなされた時点で、対立はもはやポリシー会議での意見の違いにはとどまれなかった。民間レジストリが、地域をめぐる言説とポリシーに明記がないことを使い、運用に組み込まれた資産を脅かせるのかを問う試金石になった。
事実を劇的に誇張する必要はない。公の報道は、AFRINICの紛争を、IPアドレスをめぐる単純な商事紛争が、アフリカ最大のインターネット・ガバナンス問題になったものとして描いている。また、Cloud Innovationはしばしば悪役として描かれてきたが、その後の文書資料は、AFRINIC内部の破壊的な勢力と、AFRINICの代理人がAFRINICの費用で訴訟を遅らせ、長引かせ、継続させていたことを示した、とも報じている。（btw.media）
これは重要だ。通常の語りを逆転させるからである。
構造的な失敗を生み出したのは、訴訟ではない。
訴訟が、それを露呈させた。
問題となる失敗は、民間レジストリが、明示的な許可がないことを強制的支配の根拠として扱った時点ですでに存在していた。リースは一意性への脅威ではなかった。顧客の所在地は重複割当ではなかった。商業利用はルーティングのセキュリティ障害ではなかった。レジストリが好まないビジネスモデルは、グローバル不変条件ではなかった。
それでも、レジストリの権限主張は、これらの問題を取消しの枠組みの中に置いた。
調整が統治に変わるのは、その瞬間だ。
報道によれば、AFRINICは2021年3月、Cloud Innovationに対し、ポリシー違反を主張して会員資格の終了を警告する書簡を送った。同年7月には、モーリシャス最高裁判所がAFRINICによるCloud Innovationの会員資格の終了を禁止した。同年12月には、AFRINICによる再度の会員資格取消しの試みも阻止された。（btw.media）この経過は、レジストリが落ち着いてインターネットを守ったという話ではない。レジストリの権限が、通常の法に直面したという話だ。
より広範な制度の機能不全も、レジストリの権力が足りなかったために起きたのではない。さらに深い問題は、ロックインだった。ひとつのレジストリが、価値ある稼働中の資産について独占的な承認権を握れば、内部のあらゆる失敗が、インターネットの継続性へのリスクになる。会員が承認システムから離脱できなければ、レジストリの失敗は、資産を人質に取る力になる。
レジストリは、自らの記録にある、立証可能な登録上の不正を訂正してもよい。
レジストリモデルが存在する間は、重複割当を防いでもよい。
参加者が依存している間は、セキュリティに関する表明を維持してもよい。
だが、それらは古いアーキテクチャの移行期の機能だ。
RIR後のアーキテクチャでは、それらの機能をレジストリが担うのではない。分散台帳の状態、支配権証明の規則、競合規則、そして各参加者が手元で検証できる遷移に組み込む。
民間組織が、リースを地域への反逆に変えてはならない。
顧客の所在地を、取消しの引き金にしてはならない。
商業上の不一致を、技術的な無効性として扱ってはならない。
資産の継続性を、許可の問題に変えてはならない。
AFRINICは、正しく理解された、将来の意思決定の局所化が必要であることを示している。将来の商業上の判断が「各参加者に属する」と決める中央機関があるのではない。初期仕様によって、そうした判断が最初から共通層に入り込まないようにしなければならない。リース、顧客の所在地、商業利用、価格設定、資金調達、顧客構成、導入戦略は、一意性、セキュリティ、支配権の証明、相互運用性に直接影響しない限り、決定論的な有効性の規則の外に置かれる。
ある運用者がアドレスをリースしても、他の運用者の相互運用性を壊すことはできない。
ある運用者が、歴史的なレジストリの対象地域の外にいる顧客にサービスを提供しても、他の運用者の相互運用性を壊すことはできない。
ある運用者が、レジストリの好まないビジネスモデルを使っても、他の運用者の相互運用性を壊すことはできない。
起こりうるのは、せいぜい、他の参加者が動かしている決定論的な規則を満たせないことだ。その場合、他の参加者は無効な状態をローカルに拒否する。処罰の層はない。遵守を裁く法廷もない。地域の主権者もいない。
この線引きは、思想上のものではない。
運用上のものだ。
代理権の問題は些末なことではない
AFRINICの選挙をめぐる論争は、もうひとつの欠陥を明らかにした。代表性である。
NRSは、自らが代表する根拠を、直接的な法的表現で説明している。掲載されている会員は、RIRガバナンスに関する事項についてNRSに代理を委ね、各会員が委任状を提出したという。（nrs.help）AFRINICの選挙紛争の際、NRSは会員に対し、自分の名前が投票者名簿に載っていたり、自分が参加していないのに投票が記録されていたりした場合には報告するよう求めた。そして、そのような事実の報告は合法的な経路で扱うと述べた。（nrs.help）
これは重要だ。法的な代理と、コミュニティをめぐる言説の違いを示しているからである。
RIR制度は、法人の代表者、データベース上の連絡先、技術連絡先、従業員、コンサルタント、委任状による代理人、ポリシー議論の参加者、メーリングリストの常連という、複数の区分をひとつにまとめがちだ。これらは同じものではない。
データベース上の連絡先は、記録の管理を手伝える。
委任状は、有効であり、その範囲内であれば、代理権を授けることができる。
ポリシー議論の参加者は、専門知識を提供できる。
メーリングリストで発言する人は、意見を述べられる。
そのいずれも、レジストリの判断の帰結を負うすべての企業、顧客、国家、債権者、貸し手、買い手、借り手、ネットワークについて、当然に法的な本人になるわけではない。
この区別を無視できるのは、共通層が薄いままである間だけだ。レジストリが取消し、移転、リース、市場へのアクセス、制裁の扱い、資産の継続性、国家インフラのリスクを支配する権限を主張した途端、代表性は統治の根本構造を問う問題になる。
会議の場があるだけで、権限が与えられたことにはならない。
メーリングリストは、ひとつの人民ではない。
連絡先の記録は、法人の代理権を授ける委任状ではない。
サービスの対象地域は、主権の担い手となる選挙人集団ではない。
これは手続きへの過度なこだわりではない。
調整と支配を分ける違いである。
稼働コード優先原則に基づくシステムは、そもそも代表を必要とする判断の数を減らすことで、この罠を避ける。有効性が決定論的で、各参加者が手元で確かめられるなら、投票で決める事柄は少なくなる。将来の変更が自発的なものなら、不採用者の資格に問題があるかを決める必要はない。状態が分散台帳に表されているなら、自分の存続を認めてもらうために既存レジストリに懇願する必要はない。互換性集合が明示されていれば、参加者は政治的な会議の場に尋ねなくても、誰と相互運用できるかを知ることができる。
最良のガバナンス問題とは、システム設計によって消し去られる問題である。
RIPE NCCとLACNIC：クラブと隘路
RIPE NCCとLACNICが示しているのは、あるRIRが他より文明的だということではない。RIRモデルには、技術的機能を超えた2つの執行層があるということだ。クラブと隘路である。
クラブは、誰がまともな仲間として認められるかを決める。隘路は、誰の登録状態を変更できるかを決める。
RIPE NCCが、RIPE 90に対するLARUSの協賛を受け入れなかったことは、クラブの層をはっきり示した。会員が協賛を申し出た。レジストリ側の生態系は、別の地域での無関係な紛争を理由に、それを拒んだ。これはルーティングのセキュリティに関する判断ではなかった。一意性に関する判断でもなかった。決定論的な検証規則でもなかった。会議へのアクセスを通じた、私的なブラックリスト化だった。LACNICも、私の協賛を拒んだ。地域は違っても、反応は同じだった。レジストリのクラブは、会議の場、可視性、協賛、評判、社会的な正統性を支配することで、自らを守る。
これはコミュニティではない。門番による排除だ。
制裁の層は、さらに悪い。中央にある隘路を、法的な形で示すからだ。RIPE NCCは、オランダに拠点を置くためEU制裁に従わなければならないと述べている。制裁が適用されると、RIPE Databaseでの登録を凍結し、取得と移転を阻止する。また、当事者が十分な書類を提出できない場合、その案件を凍結対象として扱うことがある。銀行との関係が支払いに影響するため、OFACのリストも照合している。（RIPE NCCの制裁に関する透明性報告）
これは、法律を守るRIPE NCCへの批判ではない。オランダの法人は、オランダ法とEU法に従わなければならない。問題はアーキテクチャだ。なぜオランダのひとつの民間法人が、多数の国、運用者、法制度にまたがる番号資源の移動について、中央の承認拠点でなければならないのか。
制裁は銀行を拘束しうる。オランダの法人を拘束しうる。取引しないことを選ぶ相手方を拘束しうる。しかし、それ以外のすべての人にとっての、世界共通の技術的有効性の条件になってはならない。
これが設計上の失敗だ。
クラブが批判者を排除できるようにする中央性は、ひとつの法域が登録上の移動を凍結できるようにもする。一方は社会的な執行であり、他方は法的な執行だ。どちらも、有効性の根拠を置くべきではない場所にレジストリが居座っているからこそ機能する。
これは、3つの原則に直接つながる。
初期仕様の最小化：クラブ内での評価、協賛資格、地域政治、制裁上の分類、評判を、共通層に持ち込んではならない。共通層に含めるべきなのは、一意性、支配権の証明、競合処理、状態遷移、セキュリティのための決定論的な規則だけだ。
将来の意思決定の局所化：法的リスク、取引相手の選択、協賛、商取引上の信頼、制裁への曝露は、それを負う当事者に属する。オランダの法人は、取引を拒否してもよい。銀行は、支払いを拒否してもよい。相手方は、取引関係を拒否してもよい。しかし、そのどれも、レジストリにおける普遍的な真実になってはならない。
自発的な採用：参加者は、コードを動かし、状態を検証し、誰と相互運用するかを選ぶことによって、相手方を受け入れる。不採用は不正行為ではない。ローカルな拒否は、世界全体での無効性ではない。クラブの拒否が、有効な状態を消し去ってはならない。制裁上の義務は、その義務に服する当事者を制約すべきであり、世界の番号資源台帳を書き換えるべきではない。
だからこそ、分散台帳の設計が必要なのだ。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制度の最初の設計が失敗したのは、稼働コードが実際に何を必要とするのかを、一度も問わなかったからだ。
問うたのは、誰が会議の場で発言できるかだった。
次のシステムは、その順序を逆転させなければならない。
権限のロンダリングではない。
稼働コードへの裏切りでもない。
稼働コード優先原則である。
付録：インターネット調整システムにおける初期仕様の最小化、将来の意思決定の局所化、自発的な採用
要旨
本書は、システムを動かす参加者の上に恒常的な権威を作り出すことなく、共通の技術的な参照点を提供することを目的とする、インターネット調整システムの設計パターンを記述する。初期仕様の最小化、将来の意思決定の局所化、自発的な採用という、相互に結び付いた3つの原則を定義する。
このモデルでは、初期仕様が定義するのは、一意性、相互運用性、支配権の証明、共通の安全性、セキュリティに必要な、決定論的で各参加者が手元で検証できる規則だけである。初期仕様が定まった後、将来の変更を中央機関が承認することはない。コードを動かす参加者が、採用し、無視し、フォークし、あるいは放棄する。
想定する設計パターンは、有効な状態を記録する分散台帳、またはそれと同等の分散型の検証可能な状態機構であり、レジストリの階層構造ではない。通常の有効性を決める常設レジストリは存在しない。参加者は状態を手元で検証し、相手方を自発的に受け入れ、どの互換性集合を動かすかを決める。
不採用は違反ではない。後の変更を採用しない参加者は、それまでの互換性集合にとどまる。別の参加者が受け入れている決定論的な規則では無効となる状態を出力する参加者は、その相手からローカルに無視されることがある。その効果は、互換性の選択、フォーク、孤立、選択的な相互運用であり、機関による処罰ではない。
本書は通信プロトコルを定義するものではない。恒久的な統治機関に変質してはならないプロトコル、識別子システム、分散台帳、調整機構を設計するための、現時点での最良の実践（BCP）を定めるものである。
1. はじめに
多くのインターネットシステムは、限定的な技術的目的から始まる。共通の参照点、識別子空間、検証規則、台帳の状態、支配権の証明記録を共有することによって、独立した当事者が相互運用できるようにするという目的だ。時間がたつにつれ、そうしたシステムは、当初の相互運用性には必要でなかった権限を蓄積しがちである。
通常、これは3段階で起こる。
第一に、技術的に必要になる前から、将来の問題が創設時の層に組み込まれる。
第二に、自分のシステムを動かす参加者が行うべき選択が、恒常的な機関による承認、解釈、地位の判断に依存するようになる。
第三に、参加者が稼働するシステムで変更を採用していない場合でも、公表、登録、勧告、手続き上の承認だけで、運用上の義務を生み出すのに十分だと扱われる。
その結果、脆いシステムができる。技術的な参照層が統治層になる。記録係が門番になる。調整のための補助物が、将来の支配の源泉になる。
本書は、別の設計上の規律を提案する。
- 初期仕様の最小化：基本的な相互運用性、一意性、支配権の証明、共通の安全性、セキュリティに必要な、決定論的な共通規則だけを定める。
- 将来の意思決定の局所化：初期仕様が定まった後の選択は、コードを動かす参加者の手元に残す。参加者は、採用、拒否、フォーク、切断、選択的な相互運用を選べる。互いに互換性のある規則を動かし続ける他の参加者の相互運用性を、どの参加者も変更することはできない。
- 自発的な採用：後の変更が現実になるのは、コードを動かす参加者による実装、運用、検証、採用を通じてのみとする。
これらの原則はつながっている。最初に規定しすぎるシステムは、将来の支配を共通層にあらかじめ埋め込む。恒常的な承認層を残すシステムは、導入後に権威が再び現れることを許す。公表を現実として扱うシステムは、文書を命令に変える。
設計の発想は単純だ。有効性は、参加者が共有された状態に照らして手元で検証できる、決定論的な規則によって決まらなければならない。参加者は、後の変更を採用しても、拒否しても、フォークしても、接続を切っても、選択的に相互運用してもよい。できるのは、せいぜい自分をある互換性集合から外すことだけだ。変更を拒むことによって、互いに互換性のあるコードを動かし続ける他の参加者の相互運用性を壊すことはできない。
これが分散台帳設計の一般的な教訓である。合意規則を実効的に適用するのは、検証コードを動かし、どの状態を受け入れるかを決める参加者であって、その上に立つ機関ではない。
2. 適用範囲
本書は、インターネット調整システムに適用する。これには、識別子システム、名前と番号の枠組み、プロトコル拡張機構、支配権証明システム、ポータビリティのためのシステム、分散台帳、その他、独立した当事者が共通の技術的な参照点に依存するアーキテクチャが含まれるが、これらに限定されない。
本書は、共通規則に反対するものではない。共通規則は、決定論的で、最小限で、各参加者が手元で検証でき、システムが実際に稼働するために必要なものに限定されるべきだと論じるものである。
本書は、特定の分散台帳の実装を要求しない。要求するのは、設計上の特性である。参加者は、常設の権威に許可や地位を尋ねることなく、共有された、または複製可能な状態に初期仕様を手元で適用し、有効性を判定できるべきである。
3. 表記規約と定義
3.1. 要求水準を示す用語
本書における大文字の要求用語は、BCP 14、具体的にはRFC 2119およびRFC 8174で定義される意味で解釈する。
3.2. 用語
初期仕様：
システムの最初の導入に必要な規則、データ構造、形式、不変条件、検証手順、状態遷移規則、競合規則の集合。
共通層：
独立した参加者が相互運用するために必要な、最小限の共有規則集合または参照構造。共通層は機関ではない。参加者が実装し、検証する技術的な実体である。
分散台帳：
常設のレジストリ、委員会、その他の権威に依存することなく、参加者が通常の有効性を検証できるようにする、複製された、または他の方法で分散された状態遷移の記録。この用語は、特定の合意アルゴリズムや実装を要求するものではない。
決定論的な検証規則：
状態、記録、遷移、表明、メッセージが、指定された規則集合の下で有効かどうかを、参加者がローカルでの計算または検証によって判断できるようにする規則。
グローバル不変条件：
一意性、基本的な相互運用性、支配権証明の完全性、共通の安全性、セキュリティを守るため、ある互換性集合の中で共通に保たれなければならない性質。
参加者：
システムを動かし、検証し、導入し、またはそれに依存する、運用者、実装、ノード、ネットワーク、組織、その他の当事者。
互換性集合：
実装している検証規則によって、互いに相互運用できる参加者の集まり。一部の参加者が後の変更を採用し、他の参加者が採用しなければ、その変更によって新たな互換性集合が生じることがある。
採用：
システムを動かす参加者による、実際の実装、導入、検証、利用。
相手方の受入れ：
自ら動かしている検証規則の下で、別の参加者の状態を受け入れ、その参加者と取引し、相互運用し、またはその状態に依存するという、参加者の自発的な判断。
不採用：
提案された変更を実装または利用しないという、参加者の選択。不採用によって無効という地位が生じることはない。その変更が作り出す互換性集合に参加していないことを意味するだけである。
ローカルでの拒否：
自ら動かしている検証規則の下で無効または非互換となる状態、メッセージ、記録、遷移を、無視し、拒否し、あるいはそれとの相互運用を行わないという、参加者のローカルな判断。
フォーク：
検証規則または運用実務が分岐し、2つ以上の互換性集合が生じること。
調整用成果物：
参加者の調整を助ける文書、勧告、実装上の注記、プロファイル、参照実装、台帳エクスプローラー、ミラー、その他の成果物。調整用成果物は、参加者が稼働するシステムで採用しない限り、拘束力のある運用上の現実を生み出さない。
4. 問題の所在
設計者はしばしば、創設時の層に多くを書き込みすぎることや、将来の問題を解釈する恒常的な機関を残すことで、将来の不確実性を減らそうとする。それは慎重に見える。しかし、多くの場合、危険である。
創設時の層での過剰な仕様化には、3つの代償がある。
第一に、将来の選択を、変更が難しく、乗っ取りの影響が大きい共通層へ移してしまう。
第二に、技術的な有効性と、機関による承認の間に曖昧さを生む。
第三に、記録を維持し、文書を公表し、参加者を招集する機関が、そうした行為を将来の現実に対する権限として扱うことを助長する。
同じ問題は、導入後にも現れる。変更の承認、地位の判断、通常の運用の解釈に恒常的な機関を必要とするなら、そのシステムは創設後の支配層を作り出している。その層は、事務管理として始まるかもしれない。やがて統治になり、さらに隘路になりうる。
本書の設計目標は、機関の裁量を改善することではない。その裁量を必要としないようにすることである。
適切に設計されたインターネット調整システムは、決定論的で各参加者が手元で検証できる有効性の規則を最初に定義し、有効な状態を分散またはその他の複製可能な形で表し、不変条件に関わらない選択を共通層の外に残し、後の変更は参加者が稼働するシステムで自発的に採用したときにのみ現実になるようにすべきである。
5. 原則1：初期仕様の最小化
5.1. 原則の定式化
初期仕様は、基本的な相互運用性、一意性、支配権の証明、共通の安全性、セキュリティに必要な、最小限の決定論的な共通規則だけを定義するべきである（SHOULD）。
5.2. 要件
この原則を用いる設計は、次の要件を満たす。
- グローバル不変条件を明示しなければならない（MUST）。
- 各グローバル不変条件について、決定論的な検証規則を定義しなければならない（MUST）。
- 有効な状態をどのように表し、複製し、検証し、更新するかを定義しなければならない（MUST）。
- 明示されたグローバル不変条件の維持、または最初の導入を可能にするために必要でない限り、初期仕様に規則を組み込んではならない（MUST NOT）。
- 検証規則を、ポリシー上の好み、事業上の取り決め、制度的役割、統治への志向、裁量的な判断から分離しなければならない（MUST）。
- 参加者が、機関、レジストリ、委員会、ポリシー策定機関、その他の権威に尋ねることなく、通常の有効性を手元で検証できるようにしなければならない（MUST）。
- ローカルでの検証に必要なデータ構造、署名、証明、状態遷移規則、競合規則、その他の機構を定義するべきである（SHOULD）。
- 将来の差異が予見できる場合、拡張の通知、バージョン管理、互換性のラベル付け、またはフォークの識別を定義するべきである（SHOULD）。
- 必須の調整用成果物が、可搬性、監査可能性、再現可能性、置換可能性を備えるようにしなければならない（MUST）。
- 主観的な価値判断よりも、機械で検証できる客観的条件を優先するべきである（SHOULD）。
- 将来の機関による承認を、有効な状態を知り、記録し、利用するための唯一の経路にしてはならない（MUST NOT）。
5.3. 設計上の含意
初期仕様の最小化は、曖昧な仕様を意味しない。共通でなければならないものだけを、厳格に定めるという意味である。
システムには、稼働するために十分な共通構造が依然として必要だ。ここでの規律は、次の2つを区別することにある。
- 一意性、相互運用性、支配権の証明、共通の安全性、セキュリティのために、共通でなければならないもの。
- 運用者の好み、事業上の実務、取引相手の選択、導入の時期、後の採用の選択に関わるため、共通層の外に残せるもの。
グローバル不変条件と決定論的な検証規則を明確に述べられない設計は、裁量を規定しすぎ、検証可能な実体を規定しなさすぎていると考えるべきである。
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）。
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 Heng