RIR 意思決定比較のためのバージョン管理イベントスキーマ

概況

既存の RIR、ICANN、IANA の報告書には相当な証拠が含まれているが、同じように見える合計値が異なる開始点、完了状態、アクターの役割、対象集団を参照することがある。
比較単位は、安定した不透明な識別子、機関の名前空間、イベントクラス、ポリシーバージョン、一連のライフサイクル状態、およびレビュー、訂正、または撤回への明示的なリンクを備えた、管理された意思決定イベントであるべきだ。
決定時間は、受理、文書完全性、実質的審査、決定、通知、権威ある実装を分離すべきであり、レビューには独自の提出、受理、中間救済、結果、救済のタイムスタンプが含まれるべきである。
アクターフィールドは、行動時の機関の役割（要求者、検証者、推奨者、決定者、実装者、レビュー担当者）を記述し、不必要な個人の身元を公開したり、役割と権限を混同したりしない。
公開イベントフィールドと保護された証拠は分離されなければならない。公開記録は、ステータス、理由クラス、タイミング、出所を公開できるが、身分証明書、法的助言、資格証明、セキュリティ資料は制御され監査可能なままである。
すべてのイベントは、それが発行されたスキーマバージョンと語彙バージョンを携行しなければならない。主要な変更には、管理された移行、並行した再表示、黙示的な書き換えではなく保存された以前のリリースが必要である。
スキーマの管理は、オープンな変更記録、公開テストベクター、利益相反の開示、バランスの取れた参加を備えた独立したマルチパーティ標準化団体が担うべきであり、それはデータセマンティクスを定義し、RIR ポリシーや個別の事例を決定しない。
番号資源社会は、オープンスキーマを提唱し、保有者と研究者を招集し、ソースに基づいた比較を公開できる。イベント ID を割り当てたり、権威ある記録を維持したり、適合性を認証したり、決定を裁定したり、スキーマ権限を運用したりすることはできない。

比較は決定の境界で失敗する

RIPE NCC 年次報告書2025、ARIN 年次報告書2025、APNIC の年次報告書アーカイブ、および ICANN のFY25 年次報告書はすべて、番号資源機関がすでにかなりの運用、財務、ガバナンス情報を開示していることを示している。IANA の月次番号資源パフォーマンスレポートは、IANA と RIR 間のリクエストのステージとターゲットを指定することで、狭い領域でさらに進んでいる。問題は開示がまったくないことではない。

比較の失敗は、読者が2つの公開された値が同じ機関の行為を説明しているかどうかを問うときに現れる。移籍は、提出時、完了とみなされた時、承認時、または権威ある登録が変更された時にカウントされる可能性がある。訂正は、公開ディレクトリ、逆委任、またはルートセキュリティオブジェクトが古いままでも、チケットがクローズされた時にカウントされる可能性がある。レビューは、提出、受理、決定、または実装としてカウントされる可能性がある。年間合計は通常、それらの区別を回復するのに十分な構造を持たない。

これが、別の包括的な証拠ポータルが根本的な問題を解決しない理由である。ポータルは互換性のない数値を収集し、それらをより秩序立って見せることができるが、より比較可能にすることはできない。ガバナンス指標の長いリストは、その重み付けが実質的な選択を隠すスコアカードにもなり得る。欠けている層はより小さく、より要求が厳しい。つまり、後の合計が計算されるイベントの共通表現である。

イベントスキーマは、機関が知っているすべてを保存しようとすべきではない。それは、結果的な決定について境界設定された主張を行うべきである。それは、比較を再構築するために必要な機関のライフサイクル、権限の源泉、アクターの役割、タイミング、結果、レビュー、公開履歴を識別する。財務、集中、会員、技術サービス指標は別の基準を持つ可能性がある。それらは、単一のデータセットが便利だからといって、このイベントモデルに流し込まれるべきではない。

範囲は証拠倉庫ではなく決定である

決定イベントは、機関が、個人または組織の権利、登録ステータス、サービスアクセス、リソースレコード、またはルートセキュリティ状態を変更できる案件を受領または開始したときに始まる。また、それらの案件が処理されるルールを変更するガバナンス決定も含まれる。共通スキーマは、割り当ておよび割り当てリクエスト、移籍、登録訂正、不利なアカウント措置、レジストリによって開始された RPKI 変更、会員決定、正式なレビュー、ポリシー決定をカバーできる。各クラスは、共有エンベロープとクラス固有のプロファイルを使用する。

スキーマは、未加工のケースファイルを吸収しない。それは正規のレジストリにならず、RDAP や WHOIS を置き換えず、証明書を発行せず、事実としての実質的所有権を記録せず、法的所有権を決定せず、スタッフと交換されたすべてのメッセージを保存しない。それらの機能は、決定に責任を持つ機関と法的システムに属する。公開スキーマは、管理された識別子を通じて保護された証拠を参照しながら、プロセスと結果をテストするのに十分な情報を公開する。

範囲はフィールドレベルで強制可能でなければならない。フィールドは、5つの質問のいずれかに答えるのに役立つ場合にのみ属する。どの案件がプロセスに入ったか、どのルールの下で、どの機関の役割が行動したか、いつ状態が変わったか、結果はどのようにレビューまたは訂正されたか？これらの質問のいずれかに結びつけることができない要求されたフィールドは、拒否されるか、別のドメイン標準に置かれるべきである。この規律は、決定スキーマが無差別な機関の書類に拡大するのを防ぐ。

クラスプロファイルは狭く保つべきである。移籍プロファイルには、送信元と受信先の関係クラス、リソースファミリー、サイズ帯域、地域間リンク、権限チェック結果、実装状態が必要である。訂正プロファイルには、影響を受ける公開サーフェス、欠陥クラス、確認時間、権威ある修復、伝播状態が必要である。レビュープロファイルには、挑戦されたイベント、立地位クラス、提出、受理、中間保護、結果、救済実装が必要である。共有名はすべてのプロファイルで同じ意味を持つべきである。

1つのイベントには1つの永続的な ID が必要

すべての管理されたイベントには、スタッフの再割り当て、ケースシステムの移行、年次報告、後の訂正を生き残る安定した識別子が必要である。それがなければ、レビューをそれが挑戦した決定に確実にリンクできず、修正されたリリースがケースを二重カウントし、2つの RIR が1つの地域間移籍の2つの脚を無関係なトランザクションとして公開する可能性がある。

識別子は不透明であるべきである。保有者名、リソース範囲、国、結果、リスククラス、提出日をエンコードすべきではない。それらの事実をエンコードすると、分類が変更されたときに識別子が脆弱になり、保護された情報を公開する可能性がある。実用的な形式は、登録された機関の名前空間と衝突耐性のあるローカル値を組み合わせる。公開値は安定しており、責任のある機関は内部のケース識別子への保護されたマッピングを保存する。

安定性は、すべての関連アクションが1つの ID を共有することを意味しない。モデルは明示的な関係を必要とする。レビューイベントは独自の ID と、挑戦された決定へのreviews_event_idリンクを持つ。訂正は独自の ID と、corrects_event_idリンクを持つ。撤回は、該当する場合、レビューと元の決定の両方にリンクする。地域間トランザクションは、各 RIR が独自のローカル決定イベントを保持しながら、共同で導出された相関 ID を持つことができる。関係タイプは、文字列の類似性では得られない意味を伝える。

ID は決して再利用されてはならない。撤回されたリクエスト、拒否された申請、またはエラーで作成されたイベントも、その識別子を占有し続ける。機関が2つの ID が1つの案件を表すと判断した場合、マージ関係を公開し、両方の履歴を保持する。1つの案件が別々に決定可能な部分に分割された場合、分割関係を公開する。黙示的な削除は、後の分母を再現不可能にする。

独立したスキーマ団体は、機関の名前空間と識別子の構文を維持すべきであるが、運用上のイベント ID を発行すべきではない。各 RIR は、共有構文の下で独自の ID を割り当て、一意性に対して責任を持つ。クロス RIR 相関の場合、参加レジストリは、文書化されたプロトコルを通じて共有値を生成または合意する。アドボカシーグループも標準化団体の事務局もトランザクションレジストラにならない。

イベント状態はラベルではなくシーケンスである

単一の現在のステータスは、それを生成したパスを隠す。「完了」は、スタッフがリクエストを承認した、権威あるレコードが変更された、保有者に通知された、またはすべての依存する技術的サーフェスが調整されたことを意味する可能性がある。スキーマは、コンパクトな現在の状態を通常の使用のために保持しながら、状態遷移の順序付けられたシーケンスを表現すべきである。

共有ライフサイクルはreceivedで始まる。それはacknowledged、awaiting_completeness、complete_for_review、under_substantive_review、decision_recorded、implementation_pending、implemented、notified、closedに移行できる。クラスプロファイルは状態を適用不能と宣言できるが、黙示的に省略することはできない。拒否されたリクエストにも決定と通知状態がある。撤回されたリクエストは、誰がどの段階で撤回したかを記録する。承認されたが実装されていない移籍は、視覚的に未完了のままである。

遷移には理由クラスが必要である。ケースは、申請者の証拠、相手方の確認、別のレジストリ、裁判所、制裁分析、セキュリティ回復、または内部アクションを待つことができる。理由クラスは自動的に blame を割り当てない。それは依存関係を識別し、総経過時間と機関管理時間の両方を計算できるようにする。各一時停止には開始、終了、開始者の役割、ポリシー根拠がある。オープンな一時停止は年末に消えることはできない。

ステートマシンは、例外レコードが説明しない限り、不可能な遷移を拒否すべきである。イベントは決定前に実装できない。最終レビューはその提出に先行できない。通知前のクローズにはクラス固有の理由が必要である。再開は、新しいイベントを無関係なケースとして偽装するのではなく、アクターの役割と根拠を持ってクローズから再開への遷移を作成する。検証ルールは、公開前にこれらのエラーをキャッチする。

現在の状態は依然として有用であるが、それは派生されたものである。権威あるシーケンスは、追加専用の遷移と訂正のセットである。リリースは、便利なクエリのために最新の状態を公開できるが、期間、再開、撤回を計算するために必要な以前の遷移を保存する。この区別は、ダッシュボードと監査が同じ結果を再現しなければならない場合に不可欠である。

時間には複数の時計と1つの精度ルールが必要

機関が異なる方法で時計を開始および停止する場合、決定の比較は不可能である。共通エンベロープは、received_at、recorded_at、last_revised_atを要求すべきである。決定プロファイルは、該当する場合、complete_at、substantive_review_started_at、decision_at、notification_at、implementation_at、closure_atを追加する。レビュープロファイルは、review_filed_at、review_accepted_at、interim_relief_at、review_decision_at、remedy_implemented_atを追加する。

これらのタイムスタンプは異なる質問に答える。受領は、機関が認識されたチャネルを通じて案件を入手した時点を測定する。記録は、イベントがケースシステムに入った時点を測定する。完全性は、その時点で施行されていたポリシーの下で必要な資料が存在した時点を測定する。決定は、権限のある決定者が結果を確定した時点を測定する。実装は、権威あるシステムが変更された時点を測定する。通知は、影響を受ける当事者に結果が送られた時点を測定する。クローズは管理的であり、決して実装の代用とすべきではない。

すべてのタイムスタンプは、明示的な精度で UTC を使用すべきである。古いレコードが日付のみをサポートする場合、値は真夜中に変換されて正確として扱われるのではなく、日精度としてタグ付けされなければならない。推定時間には推定方法が必要である。欠損値は理由コードとともに欠損のまま残り、最も近い利用可能なマイルストーンに設定されない。これらのルールは、歴史的な再表示における誤った精度を防ぐ。

スキーマはまた、イベント時間と公開時間を区別する。月曜日に行われ、金曜日に初めて公開された決定は、保存する価値のある2つの事実を持つ。後の訂正は元の決定タイムスタンプを変更せず、訂正イベントと新しい公開リビジョンを作成する。アナリストは、それらを混同することなく、決定レイテンシ、実装レイテンシ、通知レイテンシ、開示レイテンシを測定できる。

暦時間と営業時間は両方とも導出可能であるべきだが、リリースは普遍的なベースとして総暦時間を優先すべきである。営業カレンダーは地域と年によって異なる。各機関は、カレンダー識別子、祝日、サービス時間の前提を公開できるため、管理された変換によってローカルの営業時間を生成できる。営業日のみを公開すると、週末、祝日、緊急処理の違いが隠される。

アクターフィールドは伝記ではなく役割を記録すべき

決定的な説明責任の質問は、自然人としての公的な身元ではない。それは、権限のある役割が行動したかどうか、職務が分離されていたかどうか、そしてその時点で権限が存在したかどうかである。したがって、スキーマはアクターの役割を名前とは独立してモデル化すべきである。

共通の役割語彙には、要求者、影響を受ける保有者、受理担当官、証拠検証者、実質的審査者、推奨者、決定者、実装者、通知者、独立したレビュー担当者、外部権限、監査オブザーバーが含まれる。プロファイルは、バージョン管理された拡張を通じてのみ役割を追加できる。自由形式のタイトルを使用して、1人の人物が複数の独立した機能を実行したことを隠すことはできない。

アクター役割レコードには、イベント ID、役割コード、機関単位、権限ソース参照、委任ステータス、開始時間と終了時間、保護されたアクターキーが必要である。公開リリースは通常、役割コード、機関、分離要件が満たされたかどうかを公開する。保護されたレイヤーは、権限のある監査人またはレビュー機関のために、自然人またはサービスの身元、資格証拠、委任チェーンを保持する。

役割と権限は互換性がない。decision_makerというラベルのフィールドは、決定機能を実行した人を記録する。別のフィールドは、使用されたポリシー、委任、または法的権限を識別する。取締役会メンバーは、役職だけで全てのケースに対して権限を持つわけではない。自動化されたサービスは承認されたアクションを実装できるが、機関のポリシーが実際にその機能を割り当て、スキーマが人間の説明責任ルートを記録しない限り、実質的な決定者として説明されるべきではない。

利益相反は構造化されるべきである。イベントは、競合チェックが必要かどうか、実行されたか、開示されたか、解決されたか、そして解決クラスを述べることができる。個人の私的な利益を公開する必要はない。後の監査は保護された証拠をテストできる。このアプローチは、公開リリースを人事データベースに変換することなく、管理の比較をサポートする。

ポリシーの出所はイベント内部に属する

決定は、それが行われた時に施行されていたルールなしには解釈できない。現在のポリシーページのみにリンクすることは不十分である。なぜなら、ページは変更され、URL は一定のままである可能性があるからである。各イベントは、ポリシー手段識別子、バージョン、発効日、不変のダイジェストまたはアーカイブ参照を携行すべきである。プロファイルはまた、手順バージョンと理由コード語彙バージョンを記録する。

権限参照は、ポリシーと実装ガイダンスを区別するのに十分に具体的であるべきである。移籍承認は、移籍ポリシーとスタッフ手順を引用する可能性がある。不利な措置は、契約条項、ポリシールール、または外部の法的命令を引用する可能性がある。ガバナンス決定は、定款、協議手順、記録された決定を引用する可能性がある。スキーマは、それらの権限が合法であったかどうかを決定せず、機関が依拠したものを保存し、レビューが主張をテストできるようにする。

理由コードは安定していて境界設定されていなければならない。「管理的」または「その他」は普遍的なコンテナになることはできない。拒否は、資格、証拠、権限、ポリシーの非互換性、未解決の紛争、制裁制限、または撤回に関するものである可能性がある。レビュー結果は、支持、変更、撤回、差戻し、立地位なしで却下、遅延として却下、撤回による終了の可能性がある。自由形式のテキストは保護された記録に残り、公開コードは集計比較をサポートする。

保留中のケース中にポリシーが変更された場合、イベントは移行ルールを識別すべきである。古いポリシーが継続されたか、新しいポリシーが適用されたか、機関がケース固有の決定を行ったか？その事実は分析的に重要である。なぜなら、変更中のルールの下で処理されたバックログは、パフォーマンスや結果の変化として見える可能性があるからである。

レビューは決定と救済にリンクされなければならない

控訴統計は、基礎となる決定に結合できない場合に弱い。イベントスキーマは、レビューをファーストクラスのリンクされたイベントにするべきである。それは、挑戦されたイベント ID、レビュールート、立地位クラス、提出時間、レビューの受理または却下、中間保護、レビュー役割、結果、理由、救済、実装を記録する。

この分離は、いくつかの歪みを防ぐ。苦情は自動的に受理されたレビューではない。レビュー決定は、レジストリがそれを実装するまで救済ではない。差し戻されたケースは決定段階に戻り、リンクされたままであるべきである。裁判所命令は、レジストリの実装イベントを引き起こす外部権限イベントである可能性がある。スキーマは、レジストリを裁判所として、または裁判所をレジストリとして表現すべきではない。

公開記録は、法的提出を公開することなく、理由と結果のクラスを公開できる。それは、移籍決定が元の権限テストの失敗のために撤回されたこと、またはレビューが立地位の欠如のために却下されたことを示すことができる。一方、保護されたレイヤーは文書を保持する。理由クラスさえも小規模コホート内の人物を識別する場合、公開は遅延または集約される可能性があるが、機密の適合性チェックは依然としてそれを含む。

中間救済にはタイムスタンプと範囲が必要である。レビューは形式的には利用可能でも、不可逆的な変更が最初に発生した場合、実際には役に立たない可能性がある。スキーマは、救済が要求されたかどうか、誰が決定したか、どのアクションが停止されたか、保護がいつ開始され、いつ終了したかを記録する。すべてのレビューが救済を受けることを規定せず、機関のルールと行動を見えるようにする。

救済は管理された語彙を使用すべきである：記録の訂正、アクセスの復元、決定の再実行、保留の解除、資格証明の再発行、訂正の公開、手数料の払い戻し、依存サービスの通知、証拠の保存、または追加措置なし。救済は、それぞれに期日と実装ステータスを持つ複数のコンポーネントを含むことができる。それらのコンポーネントが完了する前にレビューをクローズすることは、検出可能なままであるべきである。

訂正は上書きではなく追加すべき

イベントスキーマには間違いが含まれる。ソースシステムが間違ったタイムスタンプをエクスポートする可能性があり、理由が誤ってコード化される可能性があり、保護/公開の分類が失敗する可能性があり、機関が後に2つのイベントがリンクされていたことを知る可能性がある。信頼は、歴史的な消去なしの訂正に依存する。

各公開リリースは不変であるべきである。訂正されたイベントは、同じイベント ID、より高いイベントリビジョン、訂正理由、変更されたフィールドリスト、責任のある役割、訂正時間、以前のリビジョンへのリンクとともに、後のリリースに表示される。以前のリリースは利用可能なままである。消費者は最新の有効なリビジョンを選択でき、監査は以前に知られていたものを再現できる。

スキーマ表現の訂正は、基礎となる機関の決定の訂正とは区別される。決定が日付に行われたが、エクスポートが間違った日付を使用した場合、イベントリビジョンがデータを修復する。機関がレビュー後に決定を変更した場合、リンクされた撤回または置換決定イベントが機関の行為を記録する。後者をデータ訂正として扱うと、説明責任が消去される。

削除は例外的でなければならない。保護された個人データを誤って含む公開フィールドは、アクティブファイルから迅速に削除する必要があるかもしれないが、リリースカタログは、データを再現せずに影響を受けるイベントと理由を識別する墓石を保存すべきである。インシデントの保護された証拠は、権限のある調査者に引き続き利用可能である。通常の困惑、再分類、または改善された結果は削除理由ではない。

公開フィールドと保護フィールドは2つの調整された層を形成する

スキーマには、公開プロファイルと保護された証拠プロファイルが必要である。公開プロファイルは比較をサポートする：不透明なイベント ID、機関、クラス、ライフサイクル状態、役割カテゴリ、ポリシー参照、タイムスタンプ、結果、レビューリンク、訂正履歴、公開リビジョン、制限事項。保護されたプロファイルは検証をサポートする：内部ケースマッピング、身元、証拠参照、法的資料、セキュリティ詳細、公開が当事者を露出させる正確なリソース、監査人の注釈。

2つの層は識別子と整合性チェックを共有すべきである。監査人は、すべての対象となる保護されたイベントが公開表現または有効な抑制理由を持つことを確認できなければならない。公開集計は保護されたカウントと整合しなければならない。公開行は、個人データの予測可能なハッシュを使用せずに、保護された証拠へのコミットメントを携行できる。暗号設計は、各機関が即興で作るのではなく、独立してレビューされるべきである。

プライバシールールは、文書化されていないリリーススクリプトではなく、スキーマに属する。すべてのフィールドは、分類、目的、許可されたオーディエンス、保持クラス、集約ルール、レビュー日を持つべきである。イベントプロファイルは、最小セルサイズとリンケージリスクを指定すべきである。あるテーブルでは無害なイベント ID が、まれな裁判所の行動や小さな地域コホートに結合されると識別可能になる可能性がある。

したがって、安定した ID は無制限の公開結合可能性を必要としない。保護されたレイヤーは正規のイベント ID を保持する。公開リリースは、特に機密性の高いプロファイルについてはスコープ付き仮名を使用でき、保護されたクロスウォークは完全性が監査される。説明責任に必要なレビューリンクは、安全な場合には公開のままにでき、制裁、紛争、身元ドメイン間のリンクは制御されたアクセスを必要とする可能性がある。公開ルールは明示的でバージョン管理されるべきである。

独立した監査は不可欠である。なぜなら、公開行だけを検査しても、一般は省略されたイベントを検証できないからである。監査人は、資格ルール、ソースシステム、抑制ログ、保護されたクロスウォークへのアクセスを必要とする。彼らの保証声明は、期間、イベントクラス、テスト、除外事項、未解決の不一致を識別すべきである。エクスポートが調整されたという理由だけで、すべての基礎となる決定が実質的に正しかったと主張すべきではない。

スキーマバージョンはすべてのイベントとともに移動しなければならない

バージョン規律なしに変更されるスキーマはトレンドを製造する。フィールドの名前が変更され、状態が2つに分割され、資格ルールが狭められ、理由コードが廃止される可能性がある。変更を保存せずに古いイベントと新しいイベントが結合された場合、見かけ上の改善は新しい定義にすぎない可能性がある。

すべてのイベントは少なくとも4つのバージョンを携行すべきである：スキーマエンベロープバージョン、クラスプロファイルバージョン、語彙バージョン、ソースポリシーバージョン。リリースカタログは公開フォーマットバージョンを携行する。これらの値は冗長ではない。プロファイルは、共通エンベロープを変更せずに移籍固有のフィールドを追加できる。語彙は、レコードを再構築せずに理由コードを明確化できる。ポリシーは、技術スキーマが安定している間に変更できる。

メジャーバージョンは意味または互換性を変更する。マイナーバージョンは後方互換性のあるオプション機能を追加する。パッチバージョンは、意図されたセマンティクスを変更せずに仕様エラーを修正する。独立した標準化団体は、すべてのリリースに変更分類を公開し、古いレコードがどのように動作するかの例を提供すべきである。機関は、移行義務を回避するために低いバージョンラベルを選択すべきではない。

非推奨にはスケジュールが必要である。フィールドは最初に、置換とマッピングルールとともに推奨されなくなる。定義された期間は有効のままである。削除はメジャーバージョンでのみ発生する。消費者は機械可読な通知を受け取り、歴史的レコードはそれらを管理したバージョンを識別し続ける。後のパーサーは、古いフィールドが新しいものと同じ意味を持つと推測すべきではない。

地域の手順が異なるため、拡張は必要である。拡張は登録された名前空間を使用し、その目的を述べ、資格、状態、または結果に影響を与えるかどうかを宣言する。コア適合性レポートは使用された拡張をリストする。地域拡張は、コアフィールドの名前を保持しながら再定義することはできない。違いがコアの意味を変更するほど重要である場合、それは標準化変更プロセスに属する。

移行は管理された変換である

歴史的な比較には、古いイベントを新しいバージョンに再表示する必要があるが、移行はソースが含んでいなかった精度を発明する可能性がある。管理された変換は、ソースイベント、変換コード、マッピングバージョン、実行時間、オペレーター、検証結果を保存しなければならない。それは派生表現を作成し、元の証拠を書き換えない。

マップされたすべてのフィールドには出所クラスが必要である。Direct は、ソースが同じ命題を含んでいたことを意味する。Derived は、決定論的ルールがそれを計算したことを意味する。Inferred は、証拠が境界設定された結論をサポートしたが、正確なフィールドはサポートしなかったことを意味する。Unknown は、歴史的レコードが値をサポートしなかったことを意味する。Inapplicable は、イベントクラスがそれを必要としなかったことを意味する。これらのクラスは、空白がゼロになり、近似日付が正確なタイムスタンプになるのを防ぐ。

メジャーマイグレーションは対照表を公開すべきである。それは、保存、名前変更、分割、結合、廃止、新たに利用不可になったフィールドを識別する。代表的な歴史的イベントのセットは、合成または安全に編集されたデータを備えた公開テストコーパスになる。独立した実装者は変換を実行し、バージョンが受け入れられる前に結果を比較する。

意味的な変更がトレンドに影響を与える場合、並行した再表示が必要である。少なくとも1つの移行期間について、機関はソースデータが許す場合、新旧両方のバージョンで結果を公開すべきである。その差は定義変更の影響を定量化する。再表示が不可能な場合、リリースは継続的な線を引くのではなく、断絶をマークする。

移行は、RIR がケースシステムを変更する場合にも適用される。安定したイベント ID とライフサイクル履歴は生き残らなければならない。ソースシステムの識別子は変更される可能性があるが、保護されたマッピングが移行を記録する。移行前後のカウントは、撤回、再開、抑制されたイベントを含めて整合すべきである。決定関係やタイムスタンプが意味を失う場合、データベースのコピーだけでは十分ではない。

地域間イベントには中央管理なしの相関が必要

地域間移籍は、イベント関係が重要である理由を示している。2つの RIR は異なるポリシーの下で異なる決定を下す可能性があるが、トランザクションは共有リソース範囲を持ち、それらの権威ある状態が一致しない間はグローバルに完了できない。共通スキーマは、ローカルの自律性とリンクされた結果の両方を表現すべきである。

各 RIR は、独自のイベント ID、ポリシーの出所、ライフサイクル、アクターの役割、結果を公開する。ペアはまた、相関 ID、リソースセットのダイジェストまたは安全なサイズ帯域、合意された引き渡しマイルストーンを携行する。一方の機関が他方より先にローカル承認に達する可能性がある。スキーマは、その差を1つの集中決定にまとめるのではなく、保存する。

相関プロトコルは、誰が共有値を生成するか、両当事者がどのように確認するか、間違ったリンクがどのように訂正されるかを定義すべきである。それは、第三者が基礎となるトランザクションファイルを保持することを要求すべきではない。独立した標準化団体はプロトコルとテストベクターを維持する。参加 RIR は運用記録の管理者であり、それぞれの決定を実装する唯一の機関である。

IANA 向けの番号付けリクエストは、同じ原理を使用できる。IANA の公開パフォーマンス規律は、特定の機関境界での定義された承認、応答、実装ステージを示している。リンクされた RIR イベントは、すべての保有者向け RIR 決定が同じポリシーまたはサービスターゲットを共有していると主張することなく、IANA リクエストを参照できる。

相関はまた、機関間のレビューと訂正にも有用である。1つの RIR がレビュー後にその部分を変更した場合、パートナーはリンクされた調整イベントを公開できる。記録は、どの機関がどの権限の下で行動したか、共有状態がいつ一致したかを示す。それはグローバルな法廷を発明しない。

標準化団体は結果ではなくセマンティクスを管理すべき

単一の RIR が同業者の比較語彙を管理すべきではない。また、アドボカシーグループ、監査人、ベンダー、研究機関がスキーマを所有することで隠れた規制者になるべきでもない。管理は、その権限がセマンティクス、相互運用性、プライバシールール、適合性方法に限定された独立したマルチパーティ標準化団体にあるべきである。

その統治構成員は、5つの RIR コミュニティすべて、IANA 番号付けサービス、ネットワークオペレーター、リソース保有者、独立した技術研究者、プライバシー専門家、監査人を含むべきである。参加には、公開された所属と利益相反が必要である。どの構成員も、自身の見かけ上のパフォーマンスを向上させるためだけに、分母を弱めたり、状態を削除したり、結果を再定義したりできるべきではない。

団体は、提案、発行履歴、会議記録、ドラフトテキスト、実装レポート、記録された処分を公開すべきである。主要な変更には、パブリックコメント期間、影響分析、プライバシーレビュー、移行計画、少なくとも2つの独立した実装が必要である。緊急のセキュリティ訂正は迅速なプロセスを使用できるが、通常のルートを通じて批准されない限り失効する。

技術事務局は、仕様、名前空間レジストリ、例、検証ツールを維持できる。運用上のイベント ID を割り当てたり、日常的に保護された RIR ケースを検査したり、申請者がリソースを受け取るべきかどうかを決定したり、レジストリの決定を覆したり、ポリシーを正当と認証したりすることはできない。独立した監査人は、公開された基準の下で機関固有の保証を実行する。標準化団体は基準を維持し、フォーマットを満たすレポートを認識するが、実質的な決定は認識しない。

資金は多様化され、開示されるべきである。比較される機関によって完全に維持されるスキーマは、防御的な定義のリスクがある。1つの主要な商業ユーザーによって資金提供される団体は、そのユーザーの市場に最適化されたフィールドのリスクがある。固定拠出、上限付きシェア、公開予算、利益相反ルールは、キャプチャを減らすことができる。技術的な参加は、高額な旅費や会費なしで、小規模オペレーターや影響を受けるメンバーにも可能であるべきである。

適合性は層ごとにテスト可能でなければならない

適合性は単一のバッジであるべきではない。機関は、対象となるイベントを省略しながらレコード構文を実装したり、保護されたデータを誤分類しながら完全なイベントを公開したりする可能性がある。標準は別々の層を定義し、レポートはどの層がテストされたかを述べることを要求すべきである。

構文適合性は、ファイルがパースできるか、必須フィールドが存在するか、識別子が有効な形式を持つか、タイムスタンプが精度を含むか、列挙値が宣言された語彙を使用するかを問う。ライフサイクル適合性は、許可された状態遷移と関係の整合性をテストする。意味的適合性は、フィールドが定義された命題を表しているかどうかを判断するためにソースケースをサンプリングする。カバレッジ適合性は、対象となるソースイベントを公開されたまたは有効に抑制されたレコードに調整する。プライバシー適合性は、分類、集約、リンケージ、アクセス制御をテストする。

標準化団体は、機械可読なスキーマ、無効な例、エッジケース、テストベクターを公開すべきである。例は、完全性前の撤回、実装待ちの承認、中間救済付きレビュー、公開後の訂正、クロス RIR 相関、歴史的な日精度タイムスタンプ、抑制された小規模コホート、保留中のケース中のポリシー変更をカバーすべきである。簡単な例だけを通過してもほとんど証明されない。

監査人の適合性レポートは、バージョン、イベントクラス、期間、サンプル設計、ソースシステム、カバレッジ調整、例外、是正日を識別すべきである。1つの層での失敗は、別の層での成功によって隠されるべきではない。「スキーマ有効」は、完全、正確、プライベート、公正の省略形ではない。

認証言語にも抑制が必要である。独立した保証提供者は、リリースが指定されたテストに期間中適合したと述べることができる。それは、RIR が正しいポリシー選択を行ったことや、すべての決定が合法であったことを認証しない。標準化団体はレポートと適合性ステータスを公開すべきであるが、個別のケースの上訴機関になるべきではない。

スキーマは予測可能なゲームを妨げるべき

イベント測定が公開されると、機関は対応する。完了クロックは、スタッフがファイルを完了と宣言するのを遅らせることを促す可能性がある。決定ターゲットは、時期尚早な拒否を促す可能性がある。低い撤回率は、レビューへの障壁を促す可能性がある。クローズカウントは、実装前の管理的クローズを促す可能性がある。スキーマはこれらの代替を公開すべきである。

受領は、完全性が後になっても固定されたままである。追加資料のリクエストは、理由クラスとともにタイムスタンプ付きの遷移を形成する。拒否、撤回、放棄、実装は別々の結果である。再開されたケースはリンクされたままである。総時間は、機関管理時間が正当な一時停止を除外する場合でも、常に導出可能である。これらのルールは、測定された間隔の外に遅延を移動することを困難にする。

結果コホートは、決定後のイベントに従うべきである。1年に承認され、翌年に実装された移籍は、リリース間でリンクされたままである。訂正された登録は、元の決定を受けたコホートと訂正期間の両方に現れる。レビュー率は、対象となる決定を分母として使用し、受理、拒否、撤回されたレビューを開示する。イベントレコードは、1つの好ましいダッシュボードを標準に焼き付けることなく、これらの計算をサポートする。

理由コードはドリフトについて監視されるべきである。「その他」「申請者の遅延」「範囲外」の突然の増加は、実際の変化または分類ゲームを反映する可能性がある。適合性レポートは保護された証拠をサンプリングし、コーディングが一貫しているかどうかを公開できる。それは当事者を公開したり、すべての判断に異議を唱えたりすべきではない。

スキーマ団体は3年ごとに測定を評価すべきである。決定をサポートしないフィールド、比例して実装できないフィールド、不必要なプライバシーリスクを生み出すフィールドは、バージョン管理されたプロセスを通じて改訂または廃止されるべきである。新しいフィールドには、定義された使用法と移行計画が必要である。目的は最大収集ではなく、機関の権力が作用するポイントでの持続可能な比較可能性である。

最小限のリリースは狭く保つことができる

イベント標準は巨大な公開ポータルを必要としない。各機関は、安定した URL の下に小さなセットのバージョン管理されたファイルを公開できる。最初のファイルはイベントエンベロープテーブルである。2つ目はライフサイクル遷移を含む。3つ目はイベント関係を含む。4つ目は公開アクター役割レコードを含む。5つ目は、スキーマバージョン、ダイジェスト、カバレッジ、抑制カウント、訂正、適合性レポートを含むリリースカタログである。

人間可読な要約は、別々の数値として維持されるのではなく、これらのファイルから生成されるべきである。移籍ダッシュボードは、決定と実装の分布を計算できる。レビューページは、結果と救済の完了を示すことができる。年次報告書は同じ派生合計を引用できる。訂正が到着すると、カタログはどのリリースと要約が変更されたかを識別する。

最小限の公開フィールドは、イベント ID、機関名前空間、イベントクラス、現在の状態、ポリシーバージョン、受領時間と精度、決定時間、該当する場合は実装時間、結果クラス、公開アクター役割、レビューリンク、訂正リビジョン、スキーマバージョン、公開メタデータである。オプションのクラスプロファイルは、そのタイプの決定を解釈するために必要なフィールドのみを追加する。

集計テーブルは、プライバシーとコミュニケーションに依然として有用である。それらは、使用された正確なイベントクエリ、スキーマバージョン、期間、包含ルールを名前付けるべきである。公開されたパーセンテージは、プライバシーが許せば公開ファイルから、または許さなければ監査人検証済みの保護されたクエリから再現可能であるべきである。集計はイベントレコードに対するビューであり、競合する真実のソースではない。

オープンライセンスと永続的なアーカイブが重要である。研究者は、取締役会やコミュニティが主張を行ったときに利用可能だったリリースを取得できるべきである。改訂されたファイルは以前のものを上書きすべきではない。ファイルダイジェスト、署名付きカタログ、独立したミラーは、ミラーに運用レジストリ権限を移譲することなく整合性をサポートできる。

番号資源社会はアドボカシーの役割のみを持つ

番号資源社会は、保有者が比較可能な決定記録に値することを主張し、定義が分岐する場所についてソースにリンクされた研究を公開し、メンバーと技術専門家を招集し、独立した標準化プロセスを通じてスキーマ提案を提出することにより、建設的な貢献ができる。メンバーの明示的な権限により、決定記録やレビューリンクが経験したプロセスを表現できなかった方法をそのメンバーが説明するのを支援できる。

NRS は、名前空間レジストリを維持したり、RIR イベント ID を割り当てたり、保護されたケースエクスポートを受信したり、相関サービスを運用したり、適合性を認証したり、スキーマ紛争を裁定したり、RIR の結果が正しかったかどうかを判断したりすべきではない。それらの機能は、それぞれの明確な権限に従って、独立した標準化団体、責任のあるレジストリ、任命された監査人、認識されたレビュー機関に属する。

その比較研究は、欠落した公開フィールドと失敗した機関の義務を区別すべきである。レジストリは、有効なプライバシー理由でフィールドを保護し、同時に機密のカバレッジテストを通過する可能性がある。別のレジストリは、異なるレガシー定義の下でフィールドを公開する可能性がある。NRS はギャップを文書化し、証拠を求め、変更を提唱できる。その好ましい解釈を権威あるレジストリレコードに変換することはできない。

NRS はまた、自身のドメインにおいて、ポリシー提出、会員決定、訂正をバージョン管理し、それらをアドボカシーまたは会員記録としてラベル付けすることで、良い実践をモデル化できる。NRS の会員資格の主張は、NRS が番号資源を割り当て、登録し、移転し、認証したという証拠ではない。この境界は、NRS に言及するすべての公開比較に現れるべきである。

積極的な役割は永続的な監視である。アドボカシーグループは、分母が静かに変更されたり、レビューリンクが消えたり、実装タイムスタンプが管理的クローズに置き換えられたりしたときに気付くことができる。彼らはそれらの質問をメンバーに理解可能にできる。公的な推論の質を向上させるために運用権限は必要ない。

採用は2つのイベントクラスから始めるべき

実践的なロールアウトは、移籍決定と登録訂正から始めるべきである。それらは結果的な権限を行使し、可視的な技術的結果を持ち、受領、決定、実装、レビュー、訂正リンクの必要性を露呈する。また、一度にすべてのガバナンスプロセスをカバーすることをスキーマに要求することなく、地域間相関とプライバシー問題を明らかにする。

最初のフェーズでは、参加機関は内部状態をドラフト共通ライフサイクルにマッピングし、合成テストレコードを公開する。標準化団体は、パフォーマンスの違いではなく、意味的な競合を解決する。機関はより多くのローカルステージを持つ可能性がある。それは、各共通命題を満たすステージを識別し、ローカルの詳細を拡張として保存しなければならない。

第2フェーズは、境界設定された歴史的コホートを使用する。各機関は、すべてのフィールドに出所クラスを付けて定義された期間を再表示し、未知を公開し、独立した観察の下でカバレッジ調整を実行する。この演習は、仮定で埋めるのではなく、マッピングの失敗と矛盾するソースレコードを報告すべきである。

第3フェーズは、固定された周期で現在のイベントを公開し、レビューと訂正をリンクし、プライバシーと適合性の監査を実行する。クロス RIR 移籍ペアは相関をテストする。公開ユーザーは、総受領から実装までの分布やレビュー救済完了などの合意されたクエリの小さなセットを再現し、共通セマンティクスが機能することを確認する。

それらのクラスが安定して初めて、標準は不利なアカウント措置、会員決定、RPKI レジストリアクション、ガバナンス決定を追加すべきである。各追加には、独自のプロファイル、脅威モデル、公開/保護の境界、テストコーパスが必要である。チェックリストによる拡張は、この設計が避けようとしている焦点のない証拠パックを再作成する。

スキーマはポリシーをランク付けせずにプロセスを比較できる

比較可能なイベントは同一のポリシーを意味しない。ある RIR は、移籍クラスに対して追加の証拠を要求するかもしれない。別の RIR は異なる会員資格ルールを持つかもしれない。法的制限、言語、市場状況、サービス設計は異なる。スキーマは、それらを無効と宣言するのではなく、ポリシーの出所、クラス、理由フィールドを通じてそれらの違いを記録する。

研究者は、類似のイベントクラスの総時間とステージ固有のタイミングを比較し、決定がどの程度頻繁にレビューに進むかを調べ、どの救済が未実装のままかを識別し、定義変更がトレンドを説明するかどうかをテストできる。コミュニティは、ポリシー変更の前後で自身の履歴を調べることができる。監査人は、対象となるイベントがリリースに到達したかどうかを再構築できる。これらは防御可能な使用法である。

複合リーグテーブルは正当化が難しい。証拠レビューが異なる場合、より速いことが常に公平であるとは限らない。より多くの撤回は、質の悪い最初の決定ではなく、アクセス可能なレビューを反映する可能性がある。より多くの訂正は、より強力な検出を反映する可能性がある。スキーマは事実と制限を提供し、政治的加重を選択しない。後のスコアは、標準から権限を借用するのではなく、そのクエリ、コホート、前提、感度を開示すべきである。

イベントスキーマはまた、法的所有権、実質的支配、運用上の使用、ネットワークの安全性を証明できない。それは、認識された機関が何を決定し、プロセスがどのように進んだかを記録する。有効なイベント行は、それでも紛争中または違法な決定を表す可能性がある。レビュー、裁判所、ポリシープロセス、技術的観察は引き続き必要である。

その限界は強みである。狭いスキーマは、普遍的な真実を約束しないため、正確なセマンティクスを達成できる。それは機関の行為を追跡可能で比較可能にし、実質的な権限をそれが属する場所に残す。

既知の証拠ギャップは可視のままであるべき

現在の公開レポートは、すべての RIR の完全なイベント構造、内部役割バインディング、保護された証拠マッピング、歴史的タイムスタンプを明らかにしていない。したがって、この記事は、共通マッピングが損失なしで完了できること、または名前付きの機関が現在適切な内部管理を欠いていると主張しない。年次報告書と公開ガバナンス文書は、出力を示しているが、すべてのケースシステムフィールドを示しているわけではない。

歴史的レコードは、粗い日付、変化するケース識別子、不完全なレビューリンクのみをサポートする可能性がある。一部のイベントクラスは、識別リスクなしに公開リリースにはあまりにもまれである可能性がある。ポリシーは、アーカイブされた機械可読バージョンなしで変更された可能性がある。これらは、出所、精度、抑制ステータスを公開する理由であり、完全なレコードを製造する理由ではない。

改訂されたドラフト RIR ガバナンス文書、NRO RIR ガバナンスマトリックス、合同 RIR 安定基金は、説明責任と継続性のための制度的コンテキストを提供する。それらはここで提案されたイベントスキーマを定義しない。RIPE NCC 四半期制裁透明性レポート2026年第2四半期は、結果的な制限がプライバシーに注意を払って集計で報告できることを示しているが、1つのグローバルイベント語彙を確立するものではない。

実装コストも不確実である。RIR はソースシステム、法的義務、歴史的データ品質が異なる。パイロットは、スタッフの労力、マッピング例外、プライバシー調査結果、監査コストを公開すべきである。標準化団体は、その証拠を使用して、迅速な採用を主張するために意味的整合性を低下させるのではなく、コアを比例的に保つべきである。

決定はダッシュボードが変わっても追跡可能であるべき

永続的な質問は単純である。後の読者は、機関が何を受領したか、どのルールが適用されたか、どの役割が決定したか、権威ある効果がいつ発生したか、レビューが結果を変更したか、公開レコードを管理したスキーマの意味は何かを再構築できるか？今日、年次ナラティブとダッシュボードはしばしば断片のみに答える。

バージョン管理されたイベントスキーマは、それらの出版物を置き換えない。それはそれらに再現可能な基盤を与える。安定した ID はアイデンティティを保存する。ライフサイクル遷移はシーケンスを保存する。役割フィールドは、不必要な伝記なしに機関の責任を保存する。ポリシー参照は権限の主張を保存する。レビューと訂正リンクは救済を保存する。公開と保護のプロファイルは、精査と機密性の両方を保存する。バージョン管理された移行は、時間の経過に伴う意味を保存する。

スキーマのガバナンスはそのフィールドリストと同じくらい重要である。独立したマルチパーティ団体は、運用上の決定の外側に留まりながら、定義、移行、テストを維持すべきである。RIR は記録と権限を保持すべきである。監査人はカバレッジとセマンティクスをテストすべきである。研究者とアドボカシーグループは証拠を問いただすべきである。保有者は、自分たちに影響を与えた決定の経路を認識できるべきである。

結果は、普遍的なレジストリガバナンス証拠パックよりも意図的に野心的ではない。すべての KPI を収集したり、すべての機関をランク付けしたり、保護されたレコードを集中管理したりしない。比較が繰り返し破綻する狭い継ぎ目、すなわち機関のイベント自体を標準化する。

2030年までに、結果的な RIR の決定は、ケースがクローズされた後に年間合計に溶解すべきではない。それは、新しいダッシュボード、新しいケースシステム、新しい世代の機関の主張を生き残る、バージョン管理され、境界設定され、レビュー可能なイベントとして残るべきである。

ソース

RIPE NCC 年次報告書2025- リソース、移籍、レジストリチェック、サービス、保証、財務、会員報告の現在の例。実質的な機関開示と共有イベント表現の間のギャップを特定するために使用。
ARIN 年次報告書2025- 現在の企業、選挙、ポリシー、理事会、運用報告。共通イベントスキーマではなく、機関固有の開示の証拠として使用。
APNIC 年次報告書および監査報告書- 独立した財務保証と組み合わせた運用報告の例。財務監査が決定イベントセマンティクスを検証することを意味しない。
ICANN FY25 年次報告書- より広い調整レイヤーでのガバナンス、透明性、パフォーマンス、財務報告の例。
IANA 番号資源パフォーマンスレポート- IANA-RIR 境界での名前付きサービスステージ、ターゲット、リクエスト数、実装措置の例。
NRO RIR ガバナンスマトリックス- 既存の機関文書と説明責任の取り決めのマップ。提案されたイベントスキーマを提供しない。
ドラフト RIR ガバナンス文書バージョン2- 運用、説明責任、緊急時対応、サービス移転のための現在の公開フレームワーク。イベントデータ仕様ではなく、機関コンテキストとして引用。
合同 RIR 安定基金- RIR 間の公開された継続メカニズム。機関の安定性の取り決めと、決定イベント標準のより狭いセマンティクスおよび移行ルールを区別するために引用。
RIPE NCC 四半期制裁透明性レポート、2026年第2四半期- 機密性とプライバシーに明示的に対処しながら、結果的な制限に関する集計報告の現在の例。
Number Resource Society FAQ- キャンペーン、ビジネス支援、ポリシー認識向上、メンバーの参加と意見表明を支援するグローバルな非営利会員組織としての NRS の説明。
Number Resource Society 憲章- 番号資源登録、説明責任、自由企業、レジストリ団体を拘束すべきであると NRS が主張する制度的限界に関する公開アドボカシー立場。運用レジストリ標準ではなく、アドボカシー教義として引用。