要約
- 地域レジストリはすでに認証済みインターフェースを用いてレコード操作を自動化しているが、フィールドを検証する API とポリシー適格性を判断する権限を持つエンジンは同じではない。
- 明確な計算と再現可能な条件をエンコードすることで、事務的遅延を減らし、矛盾を露呈し、ルールがリソース保有者に影響を与える前にシナリオテストを可能にすることができる。
- 自動化は裁量を排除せず、判断をデータ定義、証拠ランキング、デフォルト値、例外キュー、リリースタイミング、非公開のベンダーコンポーネントに移す可能性がある。
- ステータスコードは重大な拒否に対する十分な理由ではない。各決定は、該当するルール、ルールバージョン、重要な事実、失敗した条件、利用可能な修正、および人間の審査への経路を特定すべきである。
- コミュニティが明示的に機械可読バージョンに同等の権限を与えない限り、人間可読ポリシーが支配的であり続けなければならず、両者間の相違は公的に解決可能でなければならない。
- デプロイされたすべてのルールセットは、採用されたポリシーに再現可能にリンクされ、署名され、期間が設定され、申請者が過去の決定にどのバージョンが適用されたかを証明できるように保存されるべきである。
- RIR および他の合法的に権限を与えられたレジストリサービス事業者は、公開ルール、限定的例外、独立した上訴、集計結果の証拠、および決定サービスの交換能力を維持しながら、決定論的管理のみを自動化すべきである。NRS は、サービスを運営するのではなく、裏付けのある比較を提唱し公開することができる。
自動化はすでにレジストリガバナンスの一部である
選択肢は完全に手動のレジストリとコンピュータ化されたレジストリの間ではない。現代の登録はソフトウェアに依存している。ARIN はその Registration RESTful Service をデータベースと対話する安全な方法として説明し、特に人間の通信を必要としない反復的で大量のタスクに有用であると述べている。文書化されたメソッドはレコードの取得、作成、変更、削除を行う。XML ペイロードは組織、連絡先、ネットワークの詳細を運び、API キーはリクエストを関連組織またはリソースに対する権限を持つ人に接続する。Reg-RWS ドキュメントは、推測的な提案ではなく、成熟したトランザクション自動化の証拠である。
RIPE データベースは別のモデルを提供する。そのREST インターフェースは、データベースオブジェクトの認証付き作成と変更を受け付け、構造化された結果を返し、更新レイテンシを文書化している。クエリ応答は JSON、XML、またはプレーンテキストで要求できる。別のバージョンエンドポイントは、オブジェクトの特定の過去バージョンを取得できる。これらの機能により、登録操作は構造化されていない通信のやり取りよりもテスト、繰り返し、監査が容易になる。
RDAP は標準化された取得レイヤーを追加する。RFC 9083は JSON 応答オブジェクト、適合性識別子、イベント、ステータス値、通知、エラーボディを定義する。RFC 9537は応答から編集されたフィールドを識別する構造化された方法を追加する。これにより、クライアントは登録データのクラスを区別し、人間の読者のためだけに設計されたページをスクレイピングすることなく、いくつかの制限を解釈できる。
これらの手段はいずれも、割り当て、転送、または会員資格の判断をソフトウェアに丸ごと委任すべきであることを証明していない。それらはより狭いポイントを証明している：構造化インターフェースは、事実、権限、結果を確実に伝えることができる。これは機械可読ポリシーのための必要な基盤であるが、誰が決定的な事実を定義するか、どの例外が認識に値するか、または誤った拒否がどのように訂正されるかを決めるものではない。
境界は重要である。重複するネットワーク範囲を拒否するコマンドは技術的不変条件を強制している。企業文書が不十分である、転送がポリシーと矛盾する、または申請者が関連する運用条件を実証していないという決定には、より多くの判断が含まれる。両方ともエラー応答を生成する可能性がある。それらの制度的意味は同じではない。
有効なペイロードは正当な決定ではない
ソフトウェアインターフェースは形式の強制に優れている。例えば、ARIN の文書化されたメソッドは、組織に必要な連絡先がない、範囲が親を超えている、API キーに権限がない、レコードが既存のオブジェクトと競合する、またはレート制限を超えたという理由でリクエストを拒否できる。メソッドとエラーのドキュメントは、事業者にそのような失敗の実際的な説明を提供する。
これらのチェックはミスを減らす。また、一緒にまとめるべきではない3種類の異なるルールを示している。構文ルールは値が正しい形であるかどうかを問う。参照ルールは関連レコードが存在し一貫しているかどうかを問う。実質ルールは申請者が要求された結果を得る資格があるかどうかを問う。最初の2つは正確な検証が可能なことが多い。3つ目は、争われている証拠、ポリシーの目的、時間的事実、または不合理な結果を避けるために作られた例外に依存する可能性がある。
エンジンは3つのカテゴリーすべてを実行できるが、実行は正当性を付与しない。実質条件は権限のあるルールから来なければならない。その実行可能な表現への翻訳は意味を保持しなければならない。その表現に供給されるデータは適切でなければならない。結果は訂正に対して開かれていなければならない。リンクが隠されている場合、一貫性は無責任な権力の洗練された形になり得る。
同じ注意が機械可読登録データにも当てはまる。RDAP のrdapConformanceフィールドは、どの技術仕様が応答を形成したかをクライアントに伝える。イベントフィールドは登録日や最終変更日を示すことができる。通知はサービス全体の状態を説明できる。これらは価値のある慣行である。しかし、拒否された転送申請者に、どのポリシー条項が支配したか、どの証拠が受け入れられたか、どの事実が失敗したか、またはなぜ例外が適用されなかったかを伝えない。標準に準拠した応答でも、制度的に不透明であり得る。
これが、レジストリ自動化の次のフェーズは分類演習から始めるべき理由である。現在の各決定ポイントは、決定論的、証拠的、評価的、または例外的としてラベル付けされるべきである。決定論的チェックは通常自動的に実行できる。証拠的チェックは、ソースと信頼性が定義されている場合にのみ自動的に実行できる。評価的チェックは人間を支援することができるが、静かに最終判断になってはならない。例外的ケースは、コードを続行させるために偽の値を挿入するのではなく、明示的な経路を必要とする。
エンコードが真に改善できるもの
自動裁量に対する懐疑論は、注意深い形式化から得られる利点を曖昧にすべきではない。番号リソースルールには、計算、日付、階層、相互排他的条件、繰り返しテストが含まれている。これらはまさに機械消費可能な式が信頼性を向上させることができる特徴である。
ニュージーランドのBetter Rules for Government discoveryは、人間可読テキスト、疑似コード、ソフトウェアを一緒に開発することに価値を見出した。この演習は、共通の決定モデルが欠落を特定し、翻訳のギャップを減らし、シナリオテストを可能にするのに役立ったと報告している。また、すべてのルールが機械消費に適しているわけではないことも強調している。レジストリにとっての有用な教訓は、政府ではなく方法論に関するものである：形式化は、ルールがデプロイされる前に意見の相違を露呈させることができる。
OECD のRules as Code studyは、この概念を、コンピュータが一貫して適用できるルールの公式な機械消費可能バージョンとして説明している。番号リソースの場合、事業者は提出前に提案された転送や割り当てを公開ルールサービスに対してテストできる。ポリシー作成者は、草案に対して過去および合成のケースを実行できる。レビュー担当者は、抽象的な文言だけで議論するのではなく、新旧のテキストの結果を比較できる。
形式的テストは不可能な組み合わせを明らかにすることもできる。ある条項が連絡先属性を要求し、別のプライバシールールがその保持を禁止しているとする。転送条件がレジストリが安定したフィールドに記録しないイベントに依存しているとする。時間制限が週末やタイムゾーンについて曖昧であるとする。人間による管理は、非公式の調整を通じてこれらの矛盾を隠すかもしれない。実行可能な表現はそれらを強制的に可視化する。
一貫性も正当な利点である。明確な日付計算は、どのアナリストがリクエストを受け取るかに依存すべきではない。階層チェックはオフィスによって変わってはいけない。同一の入力に対して異なる結果を生み出すルールは欠陥として扱われるべきである。自動化はこの避けられない変動のカテゴリを狭め、熟練スタッフが実際に判断を必要とするケースを調査するために解放することができる。
したがって、最も強い根拠は安価な拒否ではない。より良いルール品質である。エンコードはテスト可能な命題、共通定義、再現可能な例、分配効果に関する早期証拠を生み出すべきである。節約は伴うかもしれないが、それは憲法上の正当化であってはならない。
裁量は移動する；消えない
実行可能なすべてのルールには選択が含まれている。数値閾値のように明白なものもある。他のものは一見中立なエンジニアリングの中に隠れている。あるフィールドは、ある管轄区域が複数の企業識別子を発行している場合でも、1つしか受け付けないかもしれない。日付は申請者のタイムゾーンではなくレジストリのタイムゾーンで読み取られるかもしれない。欠損値は偽にデフォルト設定されるかもしれない。名前の比較は、句読点、翻字、または法的接尾辞を不一致の証拠として扱うかもしれない。リスクフラグは、あるクラスの申請者を手動遅延に送り、別のクラスには即時回答を提供するかもしれない。
これらの選択は事前に行使された裁量である。一度埋め込まれると、スタッフの覚書や公開会議の可視性なしに何千ものケースに影響を与える可能性がある。繰り返しは選択をより重要にし、より重要でなくしない。誤った事務員はケースバイケースで訂正できる；誤ったデフォルトは同じ拒否を大規模に再現する可能性がある。
エンコードしないことを決定することにも裁量がある。レジストリはメインルールを自動化し、例外をスタッフガイドに残すかもしれない。その機関を知っている申請者はそれを要求できる。インターフェースを通じてのみ対話する人は、それが存在することさえ決して知らないかもしれない。セルフサービスの見かけ上の中立性は、機関への精通に報いる。
リリースタイミングも権力の源である。ポリシーコミュニティは変更を採択できるが、実装が完了するまで運用サービスは以前の解釈を実行し続けるかもしれない。RIPE コミュニティのPolicy Development Processは、コミュニティポリシーを RIPE NCC のビジネス慣行から明確に分離し、実装効果と作業の影響分析を求めている。その区別は、デプロイされたルールが採択されたテキストとその発効日まで追跡できる場合にのみ、コミュニティの権限を保護する。
最後に、メトリクスは裁量を生み出す可能性がある。スタッフが迅速なクローズで測定される場合、エンジンは明確化よりも拒否を好むかもしれない。測定が詐欺回避である場合、誤検出が十分な研究なしに許容されるかもしれない。測定が完了である場合、難しい申請者はリクエストを放棄するまでリダイレクトされるかもしれない。コードは組織が報いるものを忠実に最適化する。したがって、説明責任はソースコードだけでなく運用インセンティブもカバーしなければならない。
入力の政治学
ルールエンジンは世界を直接観測しない。それは表現を受け取る：レジストリレコード、企業文書、ルーティング観測、アカウント関係、証明、日付、宣言。これらの入力の品質と権限が結果を決定する。
組織の存在を考えてみよう。ある管轄区域はインターフェースを備えた信頼できる公開企業登録簿を提供するかもしれない。別の管轄区域は紙の証明書を発行するかもしれない。公的機関は法人化ではなく法律によって存在するかもしれない。小規模ネットワークは地元の法律が許可する場合、自然人によって運用されるかもしれない。エンジンが自動化された企業登録簿の応答のみを権威あるものとして扱う場合、それは管理上の便利さを実質的な適格性ルールに変換している。
ネットワーク証拠も同様に文脈依存的である。ルート観測はプレフィックスがアナウンスされたことを示すことができるが、それだけでアナウンスが許可されたかどうかを示すわけではない。RPKI オブジェクトは発信元クレームを強化することができるが、不在は詐欺ではなく非採用を反映するかもしれない。アドレス使用レポートは設定されたインフラストラクチャを説明できるが、共有システムや将来の展開を見逃すかもしれない。各ソースは異なる質問に答える。
したがって、機械可読ポリシーは単なるブール式ではなく、証拠モデルを含むべきである。各重要な事実について、公開文書は通常どのソースタイプが受け入れられるか、競合がどのように処理されるか、証拠がどの程度最新でなければならないか、そして代替案がいつ考慮されるかを述べるべきである。エンジンは運用上証拠をランク付けするかもしれないが、そのランキングの統治原則はプロプライエタリであってはならない。
入力の出所は、セキュリティに敏感な収集方法を公開することなく、申請者に理解可能でなければならない。決定は、組織名が特定された公開登録簿の現在のレコードと一致しなかったと述べることができる。詐欺検出のしきい値を開示する必要はない。権限の主張が既存の確認済み連絡先と矛盾するため、転送を一時停止することができる。疑わしいアカウント行動がどのようにスコアリングされるかを明らかにする必要はない。
この区別は、透明性に対する一般的な反論に答える。公開ルールはすべての防御信号の公開を要求しない。それらは、法的またはポリシー条件、通常の証拠経路、申請者のケースで依拠された事実、および訂正手段の開示を要求する。秘密のリスク指標はさらなる検証が必要であると判断するかもしれない；それらはレビュー不能な恒久的拒否の根拠になってはならない。
曖昧さはコンパイルで除去できない
ポリシーテキストには、合理的、現在、運用上、十分、実証された、例外的などの用語がしばしば含まれている。これらの言葉はすべての場合においてドラフトの失敗ではない。状況が異なる場合、比例性を維持することができる。それらをエンコードするには、用語を狭めること、範囲を表現すること、またはケースを人間に送ることのいずれかの選択が必要である。
危険な選択肢は偽の精度である。開発者は、ソフトウェアが値を必要とするため、「最近の証拠」を固定日数に変えるかもしれない。その数値は、コミュニティがそれを採用したことがなくても支配する。ウィンドウの1時間外に提出されたリクエストは、何年も前の文書と同じように失敗する。隠された実装の選択は、事実上ポリシーを修正した。
より良い設計は境界を示す。公開ルールは、定義された安全期間内の文書は自動的に受け入れられ、より長い期間を超える文書は通常拒否され、その間の間隔は文脈に応じたレビューを受けると述べることができる。この有界裁量は可視的で測定可能である。採用されたテキストが実際に判断を必要とする場合に判断を保持しながら、すべてのケースを人間に通すことを避ける。
曖昧さはルールメーカーへのフィードバックも引き起こすべきである。多くのケースが繰り返し同じフレーズの解釈を必要とする場合、それはルールの仕様が不十分であるか、現実が変化した証拠である。機関は例外率を公開し、コミュニティがより明確な基準を望むかどうかを尋ねるべきである。
機械可読表現は、どの分岐がエスカレーションを生成したかを記録することでここで役立つ。集計レポートは、特定の証拠ルールが複数の管轄区域にわたって遅延を生成したこと、または1つの例外が頻繁に呼び出されたことを示すことができる。これらのデータは、逸話ではなく観測された管理に基づく改革を可能にする。
未解決状態を避けるためだけに、エンジンが値を発明することを許可されてはならない。未知、競合、該当なしは異なる条件である。3つすべてを偽として扱うことは、実質的な結果をもたらす一般的なエンジニアリングのショートカットである。成熟したルールサービスは不確実性を保持し、意図的にそれをルーティングしなければならない。
理由はステータスコードよりも有用でなければならない
技術的ステータスコードはソフトウェアクライアントにとって必要である。制度的決定には不十分である。400応答は、不正な構文、無効な証拠、または失敗した実質条件を意味するかもしれない。403はアカウント権限の欠如、法的制限、または一時的なセキュリティホールドを示すかもしれない。申請者はどの問題が存在し、何ができるかを知る必要がある。
カナダのDirective on Automated Decision-Makingは、地域レジストリがカナダの省庁でなくても、関連するベンチマークを提供する。これは、人間の意思決定者を支援するシステムと置き換えるシステムの両方をカバーする。本番前の影響評価と、より高い影響レベルでは、主要な要因と救済オプションの意味のある説明を要求する。関連する範囲ガイダンスは、ルールベースのシステムが自動決定管理の対象になり得ることを明確にしている；高度な機械学習は必要ではない。
レジストリにとって、有用な決定受領書には、リクエストタイプと結果、各支配的ポリシー規定の安定した引用、有効なルールバージョン、受け入れられた重要な事実、合格、失敗、または不確かなままの条件、考慮された例外、決定日、利用可能な訂正、レビュー、上訴経路を含めるべきである。公開決定参照は、関連のないアカウントデータを公開することなく、後で検索を可能にするべきである。
理由は階層化されるべきである。ソフトウェアクライアントは構造化された理由コードを消費できる。ネットワーク事業者は簡潔な技術的詳細を受け取るべきである。取締役会、裁判所、独立したレビューアは完全な記録を必要とするかもしれない。同じ基礎となる決定が、紛争が始まった後に関連のない説明を生成するのではなく、3つのビューすべてをサポートするべきである。
理由はスタッフの関与にも耐えなければならない。「手動レビュー完了」は説明ではない。人が自動結果を上書きする場合、記録はポリシーの根拠と重要な証拠を特定するべきである。人がそれを確認する場合、申請者は何が考慮されたかを知るべきである。理由のない人間の介入は、単に不透明さをコードから通信に移すだけである。
この規律はレジストリにも利益をもたらす。明確な理由は繰り返しの質問を減らし、欠陥のあるルール分岐を明らかにし、上訴をより焦点化する。また、防御可能な拒否とサービスの失敗を区別する。ルールに自信のある機関は、防御上の秘密を明かすことなく説明できるはずである。
1つの権威あるルールには2つの可読形式が必要である
機械可読ポリシーは権威の問題を提起する。実行可能バージョンは単なる補助なのか、それとも人間可読テキストと同等の地位を持つのか？答えは含意に委ねられるべきではない。
最も安全な初期モデルは非対称である。コミュニティが採用した人間テキストが支配的であり続ける。実行可能表現は、各条件がそのテキストにトレース可能な公式実装である。競合が現れた場合、人間テキストが優先され、実行可能バージョンが修正される。これにより、ソフトウェアのメンテナーへの偶発的な権限移譲を避ける。
時間の経過とともに、コミュニティは共同執筆を選択し、テキスト、決定モデル、実行可能表現を一緒に開発するかもしれない。ニュージーランドの Better Rules の作業は、並行開発が翻訳エラーを減らすことができる理由を示唆している。しかし、同等の権限には、発散を解決するための公開手続きが必要である。データ定義の変更が編集上、運用上、または実質上のどれであるかが明確でなければならない。一見小さな技術的編集が適格性を変える可能性がある。
安定した識別子は不可欠である。文書が再フォーマットされるたびに変わる段落番号は弱いアンカーである。各ルール、定義、例外、証拠要件は、編集上の移動後も存続する永続的な参照を持つべきである。実行可能分岐はそれを指すべきである。テストケースはそれを指すべきである。決定受領書はそれを指すべきである。
ARIN のNumber Resource Policy Manualは、明示的なバージョンと変更履歴の価値をすでに実証している。ARIN の公開ポリシーページは、誰でも参加でき、新しいポリシーが実装されるとマニュアルが更新されると述べている。RIPE ドキュメントも、公開ストアに名前付きバージョンを保存している。機械可読ポリシーは、この文書規律を置き換えるのではなく、拡張すべきである。
公表されていないスタッフの解釈が実行可能条件を黙って変更してはならない。運用ガイダンスは証拠がどのように評価されるかを説明できるが、結果を変える繰り返しの解釈は公開レビューに提出されるべきである。そうでなければ、公式ルールは儀式的になり、実効ルールは別の場所に存在することになる。
バージョン証明は適正手続きの一部である
現在のコードを公開するだけでは十分ではない。数ヶ月前に行われた決定に異議を唱える申請者は、当時実際にどのルールセットが実行されたかを立証できなければならない。リポジトリ履歴は何が書かれたかを示すことができるが、必ずしも何がデプロイされたかを示すわけではない。
したがって、各リリースは、ルールセットバージョン、安定したポリシー参照、有効期間、テストスイートバージョン、実行可能ダイジェスト、サービスビルドを含む署名されたマニフェストを生成すべきである。決定受領書には、関連する公開リリース識別子を含めるべきである。レジストリは古いリリースと、開示されたテストケースをそれらに対して実行する再現可能な方法を保持すべきである。
デプロイは申請者の観点からアトミックであるべきである。異なるデータセンターやサービスチャネルが異なるポリシーバージョンを実行している場合、その状態は検出可能で短時間であるべきである。段階的リリースが不可視であるため、リクエストが1つのインターフェースでは成功し、別のインターフェースでは失敗してはならない。段階的デプロイが必要な場合、段階中に行われた重要な決定は、結果が競合する場合に申請者有利の有効な解釈の下でレビュー可能であるべきである。
緊急変更は特別な扱いが必要である。セキュリティ上の欠陥により、インターフェースの迅速な停止や狭い防御チェックが必要になるかもしれない。レジストリは権限、範囲、開始時間、レビュー期限を記録すべきである。緊急権限が、コミュニティの権限なしに実質的な適格性を変更する経路になってはならない。
バージョン証明は、自分たちの対話を自動化する事業者も保護する。レジストリが将来の有効バージョンと機械可読テストケースを公開する場合、メンバーは変更の前にシステムを更新できる。破壊的変更には、即時保護が必要でない限り、宣言された移行期間が必要である。互換性は単なる開発者の便利さではない；それはレジストリサービスへの平等な実質的アクセスに影響を与える。
基準は検証可能性であるべきであり、ステータスページへの信頼ではない。第三者は、決定のリリース識別子を公開マニフェストと比較し、引用されたポリシーバージョンが有効であったことを確認できるべきである。これは、 substantial な制度的価値を持つ控えめな暗号化の使用である。
テストケースは公開の憲法上の証拠であるべきである
ソフトウェアチームはテストを使用して回帰を防ぐ。ポリシーコミュニティは期待を定義するためにそれらを使用できる。公開スイートのケースは、特定の事実の組み合わせが受け入れられるべきか、拒否されるべきか、レビューに送られるべきかを述べることができる。境界ケースは、日付、階層、証拠の競合、例外がどのように動作するかを示すことができる。
テストはポリシー変更とともに提案されるべきであり、採択後にのみ書かれるべきではない。これにより、著者、影響を受ける事業者、実装者は具体的な結果に直面せざるを得なくなる。抽象的にコンセンサスを集める文は、国境を越えた転送、公的機関、小規模事業者、継承された登録に適用されると意見の相違を生む可能性がある。
テストは通常の成功だけを含むべきではない。不正な入力、欠落した証拠、矛盾する権威あるソース、部分的な停止、古いバージョン、取り消された権限、上訴訂正、自動回答が許可されないケースをカバーすべきである。また、レジストリの実際の会員に存在するすべてのサービス地域と法的形態からの例を含むべきである。
合成ケースはプライバシーを保護するが、歴史的分布がその設計を導くべきである。実際の例外のほとんどが名前変更、合併、またはアクセス可能な企業インターフェースのない管轄区域に関連する場合、スイートはそれらの条件を反映すべきである。クリーンな例のみを公開することは、決定論について誤った印象を与える。
結果の変更はデプロイ前に要約されるべきである。提案バージョンが以前はレビュー可能だったクラスを自動拒否に変える場合、コミュニティは最近のケースのうちいくつが影響を受けたかを見るべきである。この遡及的シミュレーションは拘束力のある予測ではないが、範囲とリスクに関する証拠を提供する。
テストは、回避を可能にする方法で欺瞞防止戦術を暴露してはならない。公開ケースは正当な経路と通常の証拠を定義でき、機密の検出制御は別途評価される。ただし、最終的な資格決定は依然として公開ルールに基づかなければならない。秘密のシグナルは追加の検証を要求するかもしれない；それが不適格メンバーの秘密カテゴリを作り出してはならない。
人間の審査は現実的でなければならず、儀式的であってはならない
最後に人間を追加しても、自動裁量を自動的に治癒するわけではない。レビューアがエンジンのスコアのみを見て、結果を変更する権限がないか、それに同意することで測定される場合、人間は確認装置である。
意味のあるレビューには、申請者の証拠、支配的なポリシー、機械可読分岐、理由記録へのアクセス、および明確化を求めるか異なる決定をする権限が必要である。レビューアは独立した理由を述べるべきである。ケースはそれらを調査するのに十分な時間で割り当てられるべきであり、申請者は失敗した自動チャネルを通じてのみではなく、アクセス可能な形式で証拠を提出できるべきである。
上訴は初期設定から制度的に分離されるべきである。ルールエンジニアや運用マネージャーは結果がどのように生成されたかを説明できるかもしれないが、解釈が適切であったかどうかの最終的な判断者であってはならない。影響に応じて、第2レベルは異なるレジストリチーム、独立したレビューパネル、またはコミュニティ定義の上訴機関であり得る。
RIPE PDP の公開上訴規定は、ポリシー開発に関するものであり、個別のサービス決定に関するものではないが、有用な原則を具体化している：権限の行使に関する紛争は、元の決定者を超えた文書化された経路を必要とする。ソフトウェアが番号リソースサービスへのアクセスを媒介する場合、同じ論理が適用される。
時間は重要である。転送、ルートセキュリティの変更、アカウント回復は、長いレビュー中に価値を失う可能性がある。サービス基準は、通常の明確化と緊急の継続性ケースを区別すべきである。一時的な保護措置は、所有権を判断することなくレジストリ状態を保存すべきである。遅延自体が運用上の害を生み出す場合、迅速なレビューが利用可能であるべきである。
上訴結果はルールメンテナンスにフィードバックされるべきである。レビューアが特定の分岐を繰り返し覆す場合、レジストリはそれを停止または修正すべきである。ルールバージョンと理由カテゴリ別の集計覆率を公開することで、メンバーは孤立したエラーと体系的な欠陥を区別できる。
ベンダーエンジンは私的憲法になってはならない
レジストリは商用の決定エンジン、検証サービス、ポリシー管理プラットフォームを購入するかもしれない。調達は説明責任を移譲しない。レジストリはルール、証拠、結果に対して責任を負い続ける。
プロプライエタリシステムはいくつかのリスクを生み出す。サプライヤーは条件をアクセス不能な言語でエンコードし、適切な通知なくコンポーネントを変更し、決定データを保持し、独立したテストを制限し、移行を高価にするかもしれない。モデルはルールと統計的リスクスコアを組み合わせて、公的機関が結果を完全に再現できないようにするかもしれない。サービスの停止は地域全体の決定を止める可能性がある。
したがって、契約は文書化された形式でのルール、テスト、決定記録、構成のエクスポート、重要な変更の事前通知、独立したセキュリティと公平性のテスト、定義された保持と削除、継続性の取り決め、移行支援を要求すべきである。レジストリはサプライヤーが利用できない場合に縮小された手動サービスを運用できなければならない。
ベンダーの信頼性スコアが最終的なポリシー根拠であってはならない。それは追加の証拠やレビューを引き起こすことができる。最終決定は、コミュニティが承認した条件と争うことができる事実を特定しなければならない。レジストリがサプライヤーの貢献を説明できない場合、その貢献を使用してリクエストを拒否すべきではない。
英国のAlgorithmic Transparency Recording Standardは有用な開示モデルを提供する。公的機関に、アルゴリズムツールがどのように、なぜ決定を支援するかを説明するよう求めており、強制範囲は公的効果のある決定に significant な影響を与えるツールをカバーしている。レジストリの透明性記録は、資格決定についてはさらに進んで、正確なルールリリースと上訴証拠をリンクすべきであるが、公開システムレベルの説明の原則は健全である。
サプライヤーの多様性は、すべてのサプライヤーが同じ閉じられた本人確認、データ、ホスティングサービスに依存している場合には十分ではない。集中度は契約数ではなく依存関係によって評価されるべきである。機関は、調達リストに2番目のロゴではなく、テストされた出口を持つ必要がある。
透明性とアンチゲーミングは共存できる
公開実行可能ルールの反対者は、申請者がテストに合格するために提出を最適化すると主張するかもしれない。その懸念は、レジストリが詐欺を検出する場合に最も強い。ルールが正当な適格性を定義する場合には弱い。人は公開ルールに準拠して取引を整理できるはずである；それがルールの目的である。
重要な区別は、資格基準と検出方法の間にある。リクエスターが権限を持ち、最新の証拠を提供し、移転条件を満たすという要件は公開されるべきである。盗まれたアカウントを特定する正確な信号は公開される必要はない。リスクシステムはリクエストを一時停止し、隠された根拠で申請者を実質的に不適格と宣言することなく、より強力な証明を求めることができる。
秘密を過大評価することにも危険がある。一貫性がなく説明のない管理は、それ自体が攻撃対象領域を生み出す。事業者は非公式の知識を発展させ、仲介者はアクセスを販売し、コネクションのあるメンバーはどの文言が成功するかを学ぶ。公開ルールは私的な精通の利点を減らす。
レート制限、認証要件、防御応答は合理的な範囲内で保護されたままであり得る。RDAP はすでに、構造化された通知と編集マーカーが、すべてを公開することなくデータが制限されていることをクライアントに伝える方法を示している。同等の規律は、防御の詳細を保持しながら、リクエストが強化されたレビューを必要とすることを示すことができる。
透明性は脅威モデル化されるべきである。正直な申請者が決定を理解し、異議を唱えるために必要なものを公開する。暗号化が資料の悪用を可能にする狭い情報を差し控える。すべての差し控えカテゴリを記録し、明示的に承認し、独立したレビューに従わせる。「セキュリティ」が万能の説明になってはならない。
結果データは実効ルールを明らかにする
文書は意図された運用を示す。集計決定は実際の運用を示す。説明責任のある自動化に取り組むレジストリは、実効ルールが公開ルールと一致するかどうかをテストするのに十分な結果データを公開すべきである。
有用な測定基準には、タイプ別のリクエスト量、自動受け入れ、明確化、レビュー、拒否率、決定時間の中央値と上位パーセンタイル、最も一般的な理由カテゴリ、例外頻度、人間の上書き率、上訴量と結果、バージョン関連インシデント、サービス可用性、組織規模と管轄証拠タイプ別のケース分布が含まれる。小さなセルは機密性を保護するために抑制または結合されるべきである。
これらの測定基準は解釈を必要とする。高い受け入れ率は明確なルールか弱い管理を反映する可能性がある。低い上訴率は正確さかアクセス不能なレビューを反映する可能性がある。より速い決定はより良い自動化か時期尚早の拒否から生じる可能性がある。レジストリは定義を公開し、1つの好ましい指標を選択するのではなく、独立した分析を招くべきである。
理由コードは比較のために安定していなければならない。カテゴリが変更される場合、クロスウォークが系列を保存すべきである。バージョン変更は観測者が不連続を識別できるようにマークされるべきである。データは申請者による撤回とレジストリによる拒否を区別すべきである。
質的レビューも依然として重要である。決定のサンプルは、説明の質、適切な証拠、比例性、採用されたポリシーとの一貫性について検査されるべきである。独立したレビューアは、保持されたルールリリースを使用してサンプルを再現できるべきである。
公開記録には失敗を含めるべきである。リリースが誤った結果を生み出した場合、レジストリは影響を受けた期間、決定クラス、訂正、通知方法を述べるべきである。コードを静かに置き換えることは、学習と異議申し立てに必要な証拠を破壊する。
いくつかの境界は意図的に非自動のまま残すべきである
自動化への圧力は、簡単なチェックが完了すると拡大する傾向がある。日付を正確に計算するサービスは、証拠を評価するよう求められる。証拠分類器は拒否を推奨するよう求められる。推奨はデフォルトになり、デフォルトは徐々に最終決定になる。この進行を防ぐには、便利さがそれらを侵食する前に採用された明示的な境界が必要である。
1つの境界は、保有者の権限に関する真の紛争である。2つの妥当な当事者が同じ登録の支配権を主張する場合、タスクは単に文書スコアを比較することではない。企業承継、契約履歴、以前の連絡先、裁判所命令、可能性のある詐欺を調整する必要があるかもしれない。ソフトウェアは記録を整理し、不一致を特定できる。それは、説明可能な人間の理由とレビューへのアクセスなしに、正当な保有者を選択すべきではない。
2つ目の境界は、主に保護されたまたは非公開の諜報情報に基づく不利な措置である。セキュリティシステムは疑わしい行動を特定し、一時的な保留を課すことができる。恒久的な拒否、終了、再割り当てには、少なくとも実質的に影響を受ける当事者に開示でき、独立したレビューアによってテストできる証拠が必要である。そうでなければ、上訴する権利は紙の上だけに存在する。
3つ目の境界は、新しい実質的例外の作成である。エンジンはすべての分岐の外にあるケースに遭遇するかもしれない。正しい結果は未解決でありエスカレーションされ、開発者にとって最も安全に見える結果ではない。スタッフは既存の公開裁量を使用してケースを決定するかもしれないが、繰り返し発生するクラスは私的な先例の蓄積ではなく、コミュニティの明確化を必要とする。
4つ目の境界は遡及的変更である。新しいルールリリースは、支配的なポリシーがその効果を明示的に規定しない限り、完了したトランザクションのステータスを黙って変更したり、歴史的コンプライアンスを再解釈したりすべきではない。エンジンはレコードにレビューフラグを立てることができる。現在のバージョンから遡及的権限を製造することはできない。
5つ目の境界は、継続性がリスクにさらされている場合のサービス終了である。登録またはルートセキュリティ機能へのアクセスを終了することは、会員を超えた当事者に影響を与える可能性がある。自動化は通知期間を強制し、未払い額を特定することができるが、最終的な行動は権限、比例性、係争中の紛争、依存レコードの安全な取り扱いを確認すべきである。
これらの境界は遅い管理を強制する必要はない。レジストリは緊急レビュー名簿、標準証拠セット、最大応答時間を定義できる。構造化された決定支援を使用し、匿名化された先例を公開できる。ポイントは、人またはパネルが判断の責任を引き受け、システムに帰属させないことである。
境界リストは毎年公開レビューされるべきである。新しい技術により、1つの事実をより確実に確立できるようになるかもしれない。新しい悪用は追加の一時的制御を必要とするかもしれない。しかし、決定を人間の責任から自動最終決定に移すことは、ガバナンスの変更として扱われ、証拠に裏付けられ、メンバーの精査に従うべきである。
人間のレビューを隠れ蓑に使わないという対応する義務がある。人のために留保された決定でも、理由コード、ポリシー引用、時間制限、上訴が必要である。区別は、透明な機械対記録されない判断ではない。ルールが真に答えを決定する決定論的実行と、そうでない場合の説明可能な判断である。
分配的テストはリリース前に行うべきである
ルールの正確性は、通常の例に合格することによって確立されない。条件は論理的に忠実でありながら、その入力が一部のメンバーにとって生成しやすいため、不等な実質的負担を課す可能性がある。リリース前に、レジストリは新しいバージョンが組織規模、法的形式、サービス地域、言語、リソースタイプ、相互作用チャネル全体でどのように動作するかを調査すべきである。
テストは誰が受け入れられるか以上を問うべきである。誰が即時完了を受け取り、誰が明確化を求められ、誰が人間のレビューに入るか、各経路にかかる時間、どの証拠が失敗を引き起こすかを測定すべきである。最終受け入れ率を維持しながら小規模事業者の遅延を倍増させるバージョンは、アクセスを実質的に変更している。
プライバシーが保護されていれば、歴史的リプレイはベースラインを提供できる。最近のケースは関連属性に還元され、提案ルールに対して実行できる。その後、合成ケースは稀であるが重要な境界を探求できる。分析はその限界を述べるべきである：過去のリクエストは申請者が適応した後の行動を予測しないかもしれず、歴史的データは古いバイアスを反映するかもしれない。
メンバーは簡潔なリリース影響ステートメントを見るべきである。変更された分岐、影響を受けるリクエストクラス、予想される運用効果、未解決の不確実性、モニタリングコミットメントを特定すべきである。機関はレビュー日とロールバックまたは訂正をトリガーするしきい値を指定すべきである。
この規律はイノベーションを保護する。レジストリは、露出を制限し、結果を観察し、信頼できる復帰経路を保持すれば、不確実性を持って有用なルールをデプロイできる。してはならないことは、不確実性を完全に申請者が負う静かなリスクに変換することである。
NRS が提唱できること、レジストリ事業者が実行しなければならないこと
NRS が提唱する制度的ケースは、より狭く、より説明責任のあるレジストリの役割である。NRS は、耐久性のあるレジストリ機能がどのように制限されるべきかについて研究し、自動決定に関するメンバーの経験を文書化し、影響を受ける事業者を招集し、管理を予測可能で争い可能にするルールを提唱することができる。認められた権限を記録したり、権威ある登録データベースを維持したり、ルーティング証明をサポートしたり、転送を実行したり、運用継続性を維持したりはしない。これらの行為は、 competent な RIR、定義された調整役割が適用される IANA、他の合法的に権限を与えられたレジストリサービス事業者、裁判所、独立したレビュー機関に残る。
各 RIR または他の権限を与えられた事業者は、すべての自動決定をコミュニティの権限にマッピングするルールカタログを公開すべきである。事業者は、メンバーが法的または運用上の効果を生み出すことなく仮想的なリクエストを評価できるサンドボックスを提供できる；NRS ではなく運用事業者が、署名された決定受領書を発行し、過去のリリースを保持し、決定論的検証を実行し、証拠の競合と例外のために資格のあるスタッフを確保しなければならない。NRS はこれらの公開資料を評価し、権限のあるメンバーの証言を収集し、比較を公開できるが、NRS のレポートはレジストリの決定や事業者の証拠の代わりにはならない。
拡張的なニーズ評価や産業計画を復活させるために自動化を使用すべきではない。コードは主観的な予測を客観的にしない。実行可能な需要モデルは、より良い文書を持つ既存事業者を優遇し、なじみのないアーキテクチャを罰し、不確かな事業計画を偽の数値精度に変える可能性がある。最も自動化しやすい機関は、多くの場合、最も狭い権限を持つものである。
会員の説明責任は依然として必要である。メンバーは意思決定自動化の予算とリスクアペタイトを承認し、独立した保証報告書を受け取り、高い影響を与えるルールのレビューを要求できなければならない。技術コミュニティはテストと定義に参加すべきであり、影響を受ける非会員は欠陥を報告する実用的な方法を持つべきである。
権限を与えられた事業者は、交換可能な実装も維持すべきである。オープンなルール形式と公開テストは、複数のクライアントと独立した評価者を可能にする。ホルダーは適格性を理解するためにプロプライエタリソフトウェアを必要とすべきではない。決定サービス自体はポリシーを変更せずに交換可能であるべきだが、交換権限は competent なレジストリ、法的任命手段、または裁判所から来なければならない—NRS の提唱やメンバーの代表からではない。
これは肯定的な制度設計であり、技術への信仰ではない。繰り返しと正確さが美徳である場合にソフトウェアを使用し、証拠と比例性が重要である場合に公的判断を保持する。
2024年から2030年への信頼できる経路
2024年から2030年までの期間は、スタッフを排除するレースではなく、 assurance を高める一連のステップとして扱われるべきである。第1段階はインベントリである。レジストリは重要な自動チェックをリストアップし、その権限を特定し、判断の程度を分類し、メンバーに影響を与えるインターフェースを公開すべきである。
第2段階はトレーサビリティである。既存のすべての決定論的チェックは、安定したポリシーまたは技術的完全性の参照にマッピングされるべきである。エラー応答は、構文、権限、証拠、実質条件を区別すべきである。現在のルールリリースは公開識別子を受け取るべきである。
第3段階は共同開発である。実行に適した新しいポリシーには、公開議論中に決定モデル、例、境界ケース、実装分析を含めるべきである。コミュニティは発効日より前に結果の変更をレビューすべきである。人間テキストと実行可能表現は一緒に公開されるべきである。
第4段階は争い可能性である。重要な決定は構造化された受領書を伴うべきである。強化された人間のレビューと独立した上訴は、時間、アクセス可能性、権限についてテストされるべきである。集計された覆率と例外データが公開されるべきである。
第5段階は検証可能な運用である。署名されたリリースマニフェスト、再現可能なテスト、履歴保持、独立したデプロイチェックにより、各決定を実際に実行されたルールに接続すべきである。サプライヤーの出口と縮小された手動継続性は、文書化されるだけでなく、実行されるべきである。
2030年までに、成功は人なしで行われた決定のパーセンテージで測定されるべきではない。より少ない一貫性のない結果、より短い訂正時間、より明確な理由、より低い回避可能な上訴、実証可能なルール忠実性、サービスまたはサプライヤーが失敗したときの回復力で測定されるべきである。
警告サイン
いくつかの信号は、機械可読ポリシーが自動裁量になりつつあることを示すだろう。最初は、公開テキストと運用上の理由の間のギャップの拡大である。申請者が安定した条項にトレースできない一般的な拒否を受け取る場合、実効ルールは隠されている。
2つ目は例外の蓄積である。 rigid なコードを回避するために使用される大規模なプライベートガイドは、形式的表現が不完全であることを意味する。救済策はガイドを隠すことではなく、ルールをレビューし、正当な例外カテゴリを公開することである。
3つ目はプロバイダー依存である。レジストリがサプライヤーなしで決定を再現できず、履歴をエクスポートできず、停止中に運用できない場合、公的権限は私的サービスに依存することになる。
4つ目は人間の独立性の低下である。非常に低い上書き率と繰り返される成功した上訴は、第1レベルのレビューアがエンジンに従っていることを示す可能性がある。レビューの質は直接テストされるべきである。
5つ目は不安定なバージョンである。申請者が有効なルール日を立証できない場合、または2つのチャネルが異なる結果を生成する場合、形式的公開は運用との接触を失っている。
6つ目は不均等な負担である。特定の管轄区域、組織規模、技術モデルに対するより長い時間、より高い明確化率、またはより多くの失敗した検証は、入力設計が最も簡単なデータ環境を優遇していることを示す可能性がある。そのような違いは調査を必要とし、自動的な非難ではないが、不可視のままであってはならない。
一貫性はルールが説明可能な場合にのみ価値がある
機械可読ポリシーは番号リソース管理を改善できる。繰り返しの事務的変動を除去し、矛盾を特定し、提出前テストをサポートし、ルール変更を測定可能にすることができる。既存の RIR インターフェースと標準化された登録応答は、構造化自動化が技術的に普通であることを示している。
難しい問題は制度的である。コードは公開ルールを一貫して強制することもできるし、証拠、例外、リリース選択がどのようにアクセスを決定するかを隠すこともできる。違いは、権限、トレーサビリティ、理由、レビュー、バージョン証明にある。
責任あるレジストリは、現在のサービスが現在のポリシーを実装しているとメンバーに信頼させるべきではない。接続を検証させるべきである。機械の結果を自己説明的として扱うべきではない。重要な事実と支配的な条件を述べるべきである。結果を変更する力のない人間の監視を宣伝すべきではない。権限のあるレビューと独立した上訴を提供すべきである。
NRS の貢献は、その役割が非運用であるため、規律ある自動化と互換性がある：公開ルールを提唱し、メンバーの証拠を収集し、結果を比較し、RIR ガバナンスにおいて権限を与えたメンバーを代表できる。RIR および他の権限を与えられた事業者は、すべてのルーチン実行、転送認識、権威ある記録、ルーティングセキュリティアクションに対して責任を負い続ける。その分離は、新しい NRS ルールエンジンやサービスの任務を発明することなく、非公式なスタッフ判断への依存を減らすことができる。
統治原則は単純である：ルールの適用を自動化し、裁量の所有権を自動化しない。判断が残る場合、それを名付ける。コードが決定する場合、公開しバージョン管理する。決定が申請者を害する場合、説明する。機関が間違っている可能性がある場合、訂正への人間の経路を保持する。それが、機械可読ポリシーが任意の政府を隠すのではなく減らす方法である。