記録は守る。管理者は替えられるようにする。

インターネットは、「大まかな合意と動くコード」という単純な技術上の規律を土台に築かれた。標準が権威を得たのは、委員会が宣言したからではなく、実際のネットワークで機能したからだ。レジストリは、その伝統から正当性を借り受けた。ところが、その関係を逆転させ、すでに動いているネットワークをポリシーで従わせるようになった。

この修正を、私は「稼働コード優先原則」と呼ぶ。レジストリのあらゆる規則は、一つの問いに答えなければならない。これを中央で決めなければ、稼働中のインターネットの何が壊れるのか。一意性、相互運用性、記録の正確さ、セキュリティ、継続性のいずれかが損なわれるのなら、その規則は共有層に置くべきものかもしれない。何も壊れないのであれば、その規則は調整ではない。権力であり、置くべき場所はほかにある。

ノート64で私は、この種の共有台帳に共通する三つの設計原則を示した。初期仕様の最小化。すべての参加者が共有しなければならない事項だけを、各自が検証できる形で定めること。将来の判断の分散。後の変更は、それぞれの事業者が自ら決めること。自発的な採用。新しい規則が実効性を持つのは、ネットワークがそれを実行すると選んだときであり、採用しないという選択は違反ではない。

これをレジストリに当てはめると、共有層に残すのは、稼働中のネットワークに必要なものだけになる。リース、顧客の所在地、価格設定、資金調達、事業モデルの判断は、事業者、契約、市場に返す。強制力が必要な場面では、公法と裁判所に委ねる。IPアドレスを構成する数字が世界のどこでも機能するのは、誰の許可も要らないからだ。その一意性を保つ台帳も、同じように当たり前の存在であるべきだ。

土地の登記機関は、新しい所有者の計画が賢明かどうかを問わず、その土地を誰が所有するかを記録する。インターネット番号資源のレジストリも、同じように働くべきだ。移転が真正であること、番号が二重登録されていないこと、記録が正しいことを確かめたうえで、定められた期限内に記録する。AFRINIC向けの私の草案では、通常の移転は10営業日、レジストリ間の移転は20営業日としている。拒否できるのは列挙された不備がある場合だけとし、理由と証拠を文書で示し、不服申立ての権利を保障すべきだ。

アドレスの取上げも、同じように限定すべきだ。裁判所の命令または独立した判断、立証された詐欺、解消できない重複、書面による放棄、短期間に限られ審査を受けるセキュリティ上の緊急事態、あるいは通知後の料金不払いに限る。経路制御を守るセキュリティ記録は中立でなければならず、会員を従わせる手段にしてはならない。保有者同士に争いがある場合は、その争いを台帳に明示し、独立した紛争解決機関が判断するまで、最後に検証された状態を維持すべきだ。レジストリが記録係、請求者、裁判官、執行者を一身に兼ねてはならない。

責任を問える仕組みは、退出できることから始まる。携帯電話会社を変えても番号を維持できるからこそ、会社もそれを踏まえて行動する。ネットワークも、アドレスの登録を、記録、管理権限の証明、セキュリティ情報とともに、適格な後継運営者へ移せるべきだ。番号を変更することなく、去ろうとするレジストリに許可を求めることもなく。

これは、企業があるレジストリの会員をやめ、別のレジストリの会員になるという話ではない。対象は資源そのものだ。あるアドレスブロックが、一つの組織の機能不全、特定勢力による支配、紛争の中に閉じ込められ続けてはならない。

継続性は、当然のものと考えるのではなく、設計しなければならない。レジストリの記録状態は版ごとに管理し、独立した監査を受け、どの単一組織の支配も及ばない場所に複製を置くべきだ。ディレクトリサービスには、検証済みの障害時切替えが必要であり、セキュリティシステムには鍵とリポジトリの計画的な引継ぎが必要になる。ある時点のバックアップだけでは足りないからだ。レジストリ自身の緊急時対応の議論でも、別の運営者がサービスを引き継げることは、すでに認められている。まだ認められていないのは、その選択を同じ内輪の集団だけに委ねてはならないという点だ。

今のネットワークは、台帳に何が記されているかについて、レジストリの説明を信じるしかない。私が目指す最終的な姿は違う。台帳の状態を共有し、検証できるようにする。どのネットワークも、誰がどの番号を保有するかを自ら確かめられ、特定の一機関だけが有効性の根拠になることもない。分散台帳は、その実現方法の一つだ。重要なのは独立した検証と持ち運べることにあり、特定の技術、トークン、通貨ではない。

そこへ至るのに、断絶を起こす必要はない。移行は段階を踏む。制度の実態を可視化し、稼働中のネットワークの継続性を守り、リスクを負う保有者同士の連携を図る。その後で初めて、共有層を薄くした構造へ移る。移行期には、商取引の是非を判断する役割を手放せば、既存のレジストリが記録を管理し、サービスを公開し続けてもよい。AFRINIC自体も、役割が限定され、責任を問うことができ、交代も可能な運営者として存続しうる。

技術面では、実際に取り組むべき課題がある。認証、食い違う履歴、侵害された鍵、安全な引継ぎを、すべて解決しなければならない。私は、それらが存在しないふりをするより、課題として明示するほうを選ぶ。

経営陣の交代。より良い理事会によって、レジストリは一時的に改善するかもしれない。だが、次の理事会も同じ拒否権を引き継ぐ。目指すのは、より温和な主権者ではない。主権を持つという主張そのものを終わらせることだ。

政府。国家は自国の裁判所を通じて自国の法律を執行できるし、そうすべきだ。強制力を伴う判断は、その場で行われるべきである。だが、番号管理の仕組み自体を政府に渡せば、検閲、分断、経路制御への政治的圧力を招く。200近い国家が一つの台帳で合意することもないだろう。

より大きな国際機関。ICANN、レジストリ間の調整組織、あるいは国連のフォーラムにさらに権限を与えても、同じ関門を大型化するだけだ。フォーラムは恒久化されても、フォーラムであることに変わりはない。

賠償責任の拡大だけに頼る方法。レジストリに自らが引き起こした損害を賠償させれば、その行為に費用を負わせることはできる。だが、責任を負うことで支配する権利が買えるわけではない。より良い解決は、害を生む権限を取り除くことだ。