要約
- NRS は IETF の成果を公開技術コンポーネントのライブラリとして扱うべき：プロトコル形式、セキュリティメカニズム、要件語彙、レジストリ、蓄積された実装経験。採用は特定のバージョンとテストに基づくべきであり、「インターネット標準」への一般的な準拠として表現すべきではない。
- 技術適合性と機関権限は分離されなければならない。RDAP はクエリ応答を定義し、RPKI は署名付き認可オブジェクトを運び、BGP は経路を交換できるが、どれもプレフィックスの所有権、移転の有効性、事業者が使用すべきレジストリサービスを決定しない。
- 事業者の権利は明示的な NRS サービス契約から生じるべき：記録へのアクセス、管理の検証、通知、理由のある決定、訂正、不可逆的行動の前の停止、データポータビリティ、プロバイダの交代、限定責任。標準の更新は自動的にその権利スケジュールを修正できない。
- NRS は技術的に有用で制度的に代替可能になることで積極的な権威を得る。独立した実装、敵対的テスト、公開適合証拠、リハーサルされた移行は依存を増やす一方、出口は依存が主権になるのを防ぐ。
関係は貢納の拒否から始まるべき
新しい番号資源機関は、確立された名前からの正当性を求める誘惑にかられる。IETF による認知、RFC での参照、尊敬される標準技術者の参加は、提案から権威への近道に見える。NRS はその近道を拒否すべきである。
IETF は優れた仕様を生み出すことができる。プロトコルの動作を文書化し、プロトコルレジストリに値を割り当て、セキュリティの前提を明らかにし、実装経験を収集する。しかし、IETF は NRS に事業者の登録を変更したり、移転紛争を決定したり、継続性を消滅させたりする権利を与えることはできない。それらの権限は、実際にサービス関係を統治する文書のもとで明示され、受け入れられ、審査可能でなければならない。
この拒否は標準への敵意ではない。それは標準をうまく使うための条件である。プロトコルは、当事者がその作成者の政治的権威を受け入れずに採用できるときに最も価値がある。TLS は管轄を超えて接続を保護するが、そのワーキンググループをすべてのトランザクションの所有者にしない。RDAP は登録クエリを構造化するが、記録された権利を決定しない。RPKI は証明を運ぶが、保持者の権利を無から作り出さない。
NRS は同じ制度的謙虚さを採用すべきである。すなわち、このインターフェースは名前付き仕様に従う、これらの実装は相互運用する、これらのテストは合格した、これらの事業者は結果に依存している、と言うことができる。標準が我々の政策を正当化する、と言うべきではない。技術的証拠はサービスを支える。事業者の許可は機関を支える。
この区別は、レジストリの越権に挑戦するために設立された組織にとって特に重要である。ある借用された権限を別のもので置き換えることは、より現代的な技術ラベルの下で問題を再現することになる。
オープン標準はコンポーネントであり、指揮系統ではない
RFC 3935は IETF 標準の有用な説明を提供している。それは、仕様に従っていると主張する場合に何かを一貫して行う方法を記述する。使用を義務付けたり、準拠を監視したりすることを意味しない。その価値は製品間の相互運用性にある。
その説明が NRS の姿勢を定義すべきである。協会は、独立して制御されたシステム間の調整コストを削減するためコンポーネントを採用する。標準はメッセージ構文、エラー動作、暗号検証、メディアタイプ、発見、トランスポートを指定できる。準拠とは、実装がそのインターフェースで約束されたとおりに動作することを意味する。
その連鎖はそこで終わるべきである。インターフェースへの適合は、メッセージが表す主題に対する権限を確立しない。構文的に有効な登録応答には、依然として紛争中の保有者が含まれる可能性がある。有効な署名は鍵の制御を証明するが、署名者がアドレスブロックを取得した法的根拠は証明しない。正しく送信された経路は、経路がアナウンスされたことを証明するが、アナウンスするネットワークがプレフィックスを所有していることは証明しない。
したがって、NRS は2つのマップを必要とする。技術マップは仕様、バージョン、プロファイル、テストケース、実装状況をリストする。権限マップは契約、事業者の権限、法的制約、意思決定者、審査権、移行オプションをリストする。一方のマップの失敗が他方の成功によって隠されてはならない。
この分離により、標準は本来の力を発揮する。互換性が正確さを要求する場合、技術要件は正確であり得る。権利が理由を要求する場合、制度的ルールは係争中であり続けることができる。どの参加者も、制度的越権を防ぐためにプロトコルの文言を弱める必要はない。契約がプロトコルに許可されていないことを明記しているからである。
NRS は RFC シリーズ全体の威信ではなく、プロファイルを採用すべき
「RFC 準拠」は真剣なレジストリサービスにはあまりにも曖昧である。RFC シリーズには、標準化過程文書、ベストプラクティス、実験、情報、歴史、複数のストリームからの出版物が含まれる。文書は互いに更新し廃止する。オプションは両方が許容される場合でも互換性がない場合がある。
NRS は狭い採用プロファイルを公開すべきである。プロファイルは機能、正確な RFC、組み込まれたセクション、更新、正誤表、オプション機能、拡張ルール、セキュリティパラメータ、テスト方法、移行日を特定する。また、除外事項も特定すべきである。結果は、番号の権威に訴えるのではなく、再現可能なエンジニアリングコミットメントとなる。
RDAP の場合、プロファイルは実装がサポートする HTTP の使用法、応答構造、セキュリティサービス、ブートストラップ動作、編集規則を特定できる。RPKI 公開の場合、オブジェクトタイプ、リポジトリ動作、マニフェスト処理、検証期待値、障害状態を特定できる。DNS 委任の場合、ゾーンの内容を規制することなく、転送および署名手順を指定できる。
プロファイルは別のプロバイダが実装できるほど小さくあるべきである。準拠に非公開の制度的知識が必要な場合、NRS 自身のサービスが機能していてもプロファイルは失敗している。拡張ポイントは文書化されるべきであり、必須のプライベートフィールドはロックインとして扱われるべきである。
協会は「将来のすべての更新」を自動的に組み込むべきではない。後の技術文書がコスト、プライバシー、互換性、依存関係を変更する可能性がある。各重要な更新には NRS 契約に基づく採用決定が必要である。緊急のセキュリティ修正のため迅速化できるが、責任は可視のままでなければならない。
最初の憲法文は、標準は権利を割り当てられない
NRS はすべての採用プロファイルの先頭に非転換条項を置くべきである：技術的適合性は、特定された権利文書が別途定めない限り、所有権、資格、移転の有効性、契約上の地位、または管轄を決定しない。
この条項が必要なのは、技術的記録が繰り返しの使用を通じて権威を獲得するからである。運用上の連絡先として始まったレジストリフィールドが、紛争の証拠になり得る。署名付きオブジェクトが権原と誤解される可能性がある。プロトコルステータスコードが判決として扱われる可能性がある。これらの移行が暗黙的に発生する場合、誰も責任を負うことなくソフトウェアが法律になる。
この条項は技術的記録を弱くしない。署名され監査可能な記録は強力な証拠であり得る。特定の時点で認識された資格情報を使用して、記載された行為者が変更を許可したことを立証できる。二つの権威ある状態が矛盾することを示すことができる。裁判所、相手方、または審査者を支援できる。
証拠は究極の権威とは異なる。契約は記録が何を証明し、事業者がどのように異議を唱えられるかを決定する。法律は裁判所がどのような主張を認めるかを決定する。ネットワークはどの経路を受け入れるかを決定する。プロトコルはメッセージが有効かどうかを決定する。これらの命題を分離しておくことで、どの層も他の層を飲み込むのを防ぐ。
これが NRS が IETF と求めるべき限定的な関係である。IETF は相互運用可能な証拠コンテナを定義できる。NRS と事業者は、明示的な合意により、その中の証拠からどのような制度的結果が生じるかを定義しなければならない。
RDAP は線がどこにあるかを正確に示す
Registration Data Access Protocol は、その対象がレジストリ情報であるため理想的な例である。RFC 9082はクエリパターンを定義し、RFC 9083は JSON 応答を定義し、RFC 9084はセキュリティサービスを扱う。これらの仕様により、クライアントとサーバーは相互に理解できる。
それらは、名前付きエンティティがアドレス範囲に対して有効な権利を有するかどうかを決定しない。レジストリが該当する法律に基づいて特定の事実をすべての管轄で編集できるかどうかを決定しない。事業者が登録サービスを別のプロバイダに移行できるかどうかを決定しない。これらは権限とサービスの問題である。
NRS は RDAP を使用して、正確で可搬性があり、機械検証可能な状態を公開すべきである。別の資格のあるプロバイダが提供できるプロファイルを定義すべきである。明確なステータス、出典参照、編集通知、訂正チャネルをサポートすべきである。複数のサーバーに対してクライアントをテストし、複数のクライアントに対してサーバーをテストすべきである。
事業者契約は、プロトコルに欠けている権利を提供すべきである：完全な非公開記録へのアクセス、エラー訂正の能力、重要なステータス変更前の通知、拒否の理由、独立した機関による審査、移行に適したエクスポート。成功した RDAP 応答はこれらの権利のいずれも放棄できない。
この設計は標準をロックイン防止ツールに変える。プロトコルはサービス表面を再現可能にする。契約は、プロトコル準拠が不正確または強制的な決定を免除することを防ぐ。
RPKI は認証チェーンを証明するが、制度的主権は証明しない
RPKI はその出力が経路起点検証に影響を与えるため、よりセンシティブである。RFC 6480は、証明書と署名付きオブジェクトがアドレスおよび AS 番号の保持を経路認証に関連付けるインフラストラクチャを説明する。公開と検証の仕様により、独立して運用されるシステムが暗号資料を評価できる。
暗号は限定された質問に答えることができる：このオブジェクトは選択された信頼アレンジメントの下で検証されるか、どのような経路起点認証を表現するか？リソース関係の正当性に関するすべての事前の質問に答えることはできない。レジストリが基礎となる証明状態を不当に変更した場合、バリデータは新しいオブジェクトを正しく処理するかもしれないが、事業者の権利は侵害されている。
NRS は RPKI 標準を証拠機構として採用すべきであり、適正手続きの代替としてではない。そのプロファイルは、独立した依拠当事者検証、予測可能な公開、鍵のロールオーバー、マニフェストの一貫性、失効の可視性、復旧をサポートすべきである。テストには、古いリポジトリ、部分公開、鍵の侵害、競合状態が含まれるべきである。
契約は不利な機関行動を制御しなければならない。狭く定義され実証可能なセキュリティ緊急事態を除き、アクティブな経路認証を無効にする可能性のある紛争中の変更には、通知、理由、審査までの実用的な停止が与えられるべきである。移行に必要な資格情報と履歴は、リハーサルされたプロセスの下で可搬であるべきである。
ポジティブな約束は強力である：NRS は裁量的なレジストリ決定よりも検証可能な認証証拠を提供できる。しかし、その立場を得るのは、信頼アレンジメントの支配を使用して意見の相違を罰したり、出口を阻止したりできない場合のみである。
BGP は運用上の証拠であり、権原ではない
RFC 4271は自律システム間で到達可能性情報を交換するために使用される Border Gateway Protocol を規定する。稼働中のネットワークは、どのプレフィックスがどの起点からどの経路に沿ってアナウンスされるかについての本質的な証拠を提供する。
NRS はその証拠を慎重に使用すべきである。観測された経路は、運用上の制御を裏付け、継続性リスクを特定し、提案されたレジストリ変更が現在の使用と一致するかどうかをテストできる。長命で多様な観測は、紙の記録が見逃すネットワーク関係を明らかにできる。
ルーティングは権原を確定しない。顧客はプロバイダにプレフィックスを発信させることを許可できる。ハイジャッカーは権利なくスペースをアナウンスできる。有効な保有者はブロックをアナウンスしないままにできる。Anycast は複数の正当な起点を生み出す。裁判所命令や移転はルーティングが変わる前に権利を変更できる。BGP の可視性を所有権として扱うことは、運用プロトコルを財産裁判所に変えることになる。
したがって、NRS の証拠ルールは、各観測が何を支持するかを述べるべきである。経路コレクターは、ある経路がその視点からある時点で可視であったことを示すことができる。事業者の証明は、アナウンスの商業的または技術的権限を説明できる。RPKI は署名付き起点認証を追加できる。契約と法的証拠は主張の他の部分を確立する。
標準の利点は構成可能性である：いくつかの独立してチェック可能なシグナルが決定を支持できる。危険はカテゴリー崩壊である：一つの技術的に有効なシグナルが他すべてに対して主権を宣言する。NRS は前者を構築し、後者を禁止すべきである。
規範的大文字はインターフェースで止まらなければならない
RFC 2119とRFC 8174は、文書が BCP 14を呼び出す場合に大文字の要件語に定義された意味を与える。MUST は仕様の絶対要件を特定する。SHOULD は結果が理解された後、正当な逸脱を許可する。
NRS の採用プロファイルはこの語彙を正確に使用すべきである。MUST は相互運用性に必要なバイト、状態遷移、セキュリティ動作を定義できる。テストは実装が準拠しているかどうかを示すことができる。SHOULD は実装者に有効な例外を文書化するよう要求できる。
大文字は制度的管轄権を生み出してはならない。「クライアントは無効な署名を拒否しなければならない」は技術要件である。「事業者は紛争中の登録を放棄しなければならない」は、契約上の権限、証拠、審査を必要とする権利の主張である。タイポグラフィはそのギャップを埋めることはできない。
NRS 契約は、技術要件がどのようにサービス関係に入るかを明示的に述べるべきである。プロファイルバージョンを指定し、準拠が義務、サービスレベルコミットメント、または同等の中の許容可能な実装の1つであるかを説明すべきである。技術的な SHOULD が黙って制度的な MUST に変換されてはならない。セキュリティの MUST が相互運用性を壊す裁量的なポリシー例外によって弱められてはならない。
この翻訳記録はエンジニアと事業者の両方を保護する。エンジニアは、すべての大文字が主権を移譲することを恐れずに明確な仕様を書くことができる。事業者は義務の実際の源泉を特定し、有効なプロトコル動作を争うことなく制度的決定に異議を唱えることができる。
独立した実装は入場料である
NRS は、好みのベンダーが実装したからといってコアインターフェースを安定と宣言すべきではない。障害が権威ある状態、可搬性、またはルーティングセキュリティの継続性に影響を与える可能性のある機能については、少なくとも2つの独立して制御された実装がデータを交換し、意図した結果を再現すべきである。
独立性は制御に関するものであり、ブランドラベルではない。同じ隠されたライブラリを共有する2つの製品は同じエラーを繰り返す可能性がある。単一の変更権限の下で関連会社によって運営される2つのサービスは、制度的な引き継ぎをテストしないかもしれない。証拠はコードの系統、運用者、テスト所有権、共通の依存関係を特定すべきである。
相互運用性テストは成功だけでなく、不正な入力、リプレイ、重複イベント、クロックスキュー、古い状態、部分移行、鍵ロールオーバー、利用不可の依存関係、ロールバック、復旧もカバーすべきである。ハッピーパスを受け入れるが、障害時に継続性を維持できない実装は代替プロバイダではない。
テスト成果物は、セキュリティとプライバシーが許す限り公開されるべきである。第三者はプロファイルを理解し、非センシティブなケースを再現し、自己証明と独立評価を区別できるべきである。準拠を信頼できるものにするために生産データを公開する必要はない。
目標は認証劇ではない。それはプロバイダの代替可能性である。第二の実装が権威あるエクスポートを消費し、その履歴を検証し、互換性のある結果を提供できない場合、NRS はソースコードがどれほどオープンに見えても、別の制度的チョークポイントを作成したことになる。
運用上の証拠にはソフトウェアだけでなく事業者も含まれなければならない
ソフトウェア相互運用性は、仕様が機械を調整できることを証明する。番号レジストリサービスは、ストレス下で機関を調整できるという証拠も必要とする。NRS は事業者をその第二の質問の決定的な証人として扱うべきである。
パイロットは、制御検証にどのくらい時間がかかるか、小規模ネットワークが合理的に提供できる証拠、訂正がどのように処理されるか、保有者が決定を理解しているかどうか、プロバイダ変更を通じて既存の自動化が継続するかどうかを測定すべきである。誤った拒否、誤った受け入れ、ダウンタイム、スタッフ負担、未解決の曖昧さを記録すべきである。
異なる事業者クラスが重要である。多国籍バックボーン、ローカルアクセスプロバイダ、大学、クラウドプラットフォーム、小規模ホスティングビジネスは、同様の記録を保持しながらも、人員、顧客、法的制約が大きく異なる可能性がある。十分なリソースを持つ参加者にのみ機能する標準プロファイルは、技術的には相互運用可能だが、制度的には排他的である。
否定的な証拠はプロファイルに戻る定義されたルートを持つべきである。事業者がダウンタイムなしで資格情報のローテーションを実装できない場合、設計を変更すべきである。必須フィールドが検証を改善することなくセンシティブな商業構造を露出させる場合、狭めるべきである。可搬性が、受信プロバイダが拡張を解釈できないために失敗する場合、その拡張は必須であるべきではない。
NRS は正直な分母で結果指標を公開すべきである。10回の成功した移行は、読者が何回試行され、どのように失敗し、なぜ失敗したかを知っている場合にのみ意味がある。運用上の証拠は、機関が自分に都合の良い証拠を選択できない場合にのみ、権威の源泉となる。
権利スケジュールは人間可読で分離されていなければならない
技術プロファイルは複雑になる。事業者の権利はプロトコル参照の中に隠されるべきではない。NRS は、ネットワーク幹部、エンジニア、弁護士がそれぞれ理解できる、短く安定した権利スケジュールを必要とする。
スケジュールには、事業者に関連する完全な記録へのアクセス、制御を証明し更新する文書化された方法、結果的な行動の前の通知、名前付きルールに結びついた理由、訂正プロセス、独立した審査、確認された緊急事態を除く不可逆的変更の前の停止、紛争中の継続性、オープンフォーマットでのエクスポート、資格のあるプロバイダへの移行、資格情報の返却または移行、NRS がこれらの義務に違反した場合の救済を含むべきである。
スケジュールは保証しないことを述べるべきである。すべての経路が受け入れられること、すべての管轄がアドレス利益を財産として扱うこと、法的制裁や裁判所命令が適用されないことを約束できない。NRS が権限を特定し、証拠を保存し、行動を制限し、契約されたプロセスを提供することを約束できる。
この分離は、技術的ドリフトが権利を変更するのを防ぐ。新しい RDAP フィールドは通知を減らさない。改訂された RPKI オブジェクトは停止を排除しない。新しいセキュリティトランスポートは移行を裁量的にしない。権利は契約に記載された修正ルールを通じてのみ変更できる。
この設計は同意を運用可能にするためポジティブである。NRS は事業者に抑制の文化を信頼するよう求めない。優先技術の変更を生き残る権利の下で、技術的に正確なサービスを提供する。
標準の更新には採用ファイアウォールが必要
オープン標準は進化する。セキュリティ欠陥が発見され、暗号アルゴリズムが老化し、フォーマットが拡張を獲得し、運用経験が曖昧さを露呈する。NRS はメンテナンスの恩恵を受けつつ、外部の出版物が自動的に事業者の義務を修正することを防がなければならない。
採用ファイアウォールはその境界を提供する。技術委員会は提案された更新を特定し、変更された動作をマッピングし、互換性をテストし、影響声明を公開する。権利審査は、更新が証拠の負担、開示、コスト、依存関係、出口を変更するかどうかを尋ねる。事業者は通知を受ける。権限のある NRS 機関は、契約に基づき更新を採用、延期、狭化、または拒否する。
軽微な修正は、観測可能な動作や権利を変更しない場合、迅速な経路をたどることができる。セキュリティ緊急事態は一時的な統制を正当化できるが、範囲、証拠、期間、ロールバックは記録されなければならない。通常の審査後に確認されない限り、一時的な更新は失効する。
固定バージョンは確実性を与えるが、無期限の固定は脆弱性を生み出す可能性がある。動的参照はソフトウェアを最新に保つが、無制限の組み込みは将来の決定を委任する。ファイアウォールはバージョン管理と意図的なメンテナンスを組み合わせる。
最も重要なのは、拒否が可能であることである。事業者が使用するインターフェースに更新が必要ない場合、プロファイルは互換性を維持するか、移行を提供できる。正確な動作が不可欠な場合、契約はそれを拒否することの技術的結果を説明できる。NRS は「IETF が更新を公開した」を「事業者が権利を放棄した」に変換すべきではない。
等価性は、ネットワークが同一性を必要とする場所では正確で、必要としない場所ではオープンであるべき
オープン標準ポリシーは、等価性が可能な場所を特定せずに等価なソリューションを称賛することが多い。NRS はより正確であるべきである。共有プロトコル境界では、2つの実装が同一の観測可能な動作を必要とする場合がある。クライアントは、内部セキュリティ設計が革新的であるという理由だけで無効な署名を有効として扱うことはできない。受信プロバイダは、安全な移行を主張するために必要な状態遷移を無視できない。
インターフェースから離れれば、統一性は不要かもしれない。プロバイダは、必要な証拠を生成し同じ事業者権利を尊重する場合、異なるストレージモデル、プログラミング言語、人員構成、不正防止策を使用できる。あるプロバイダは専門チームを通じて制御請求を検証し、別のプロバイダは自動チェックと人間のエスカレーションを使用するかもしれない。NRS は、自らの好む内部組織を規定するのではなく、結果とエラーパスをテストすべきである。
プロファイルはそれに応じて各要件をマークすべきである：正確なインターフェース動作、結果要件、許容可能な代替、またはローカル選択。この分類は2つの逆の乱用を防ぐ。プロバイダは革新を装って共有状態を壊すことはできず、NRS は相互運用性を装ってすべての運用詳細を標準化することはできない。
事業者は同等の管理を提案するルートを必要とする。プロバイダは目的を特定し、公開基準に対して代替をテストし、理由を示すべきである。拒否は審査可能であるべきである。繰り返しの代替が成功する場合、ベースプロファイルは過度に規範的であり、改訂されるべきである。
これは主権に対する別の境界である。標準は、自律システムが満たさなければならない場所で厳格な準拠を獲得する。標準は、著者にインターフェースの背後にあるすべての機関を設計する力を与えない。
セキュリティ緊急事態は標準化団体の緊急ルールになってはならない
インターネット標準はしばしば緊急の脅威に対応する。脆弱性は迅速な非推奨、鍵交換、プロトコル変更を必要とする可能性がある。NRS は、長い制度的議論が事業者を回避可能な害にさらす前に対応する能力を必要とする。
緊急性は技術的権限と制度的権限の区別を消し去らない。技術的証拠は脆弱性、影響を受ける機能、悪用可能性、安全な代替を特定すべきである。NRS はその契約に基づき、どのようなサービス行動が必要かを決定する。IETF 文書は、執行命令になることなく説得力のある証拠となり得る。
緊急措置は可逆的な技術的封じ込めを優先すべきである。NRS は新しいトランザクションに対して脆弱なアルゴリズムを無効にし、二重検証を要求し、監視を強化し、資格情報の寿命を短くしつつ、事業者の基礎記録を保存できる。登録状態への破壊的変更はより高い基準を必要とする。
緊急通知は、仕様、影響を受けるバージョン、テスト証拠、アクション、予想期間、審査ルートを明記すべきである。機密の悪用詳細は一時的に保護され得るが、行動の法的および契約上の根拠は秘密にできない。独立した審査者は、即時のリスクが封じ込められた後、証拠を調査できるべきである。
サンセットは不可欠である。圧縮された条件下で採用されたセキュリティ対応は、元に戻すのに労力がかかるという理由だけで、データ収集や制度的統制の恒久的な拡大になるべきではない。標準メンテナンスは、NRS がメンテナンスが事業者にどのように到達するかについて説明責任を負う場合にのみ、システムを保護する。
プロトコルレジストリは番号権利と混同されるべきではない
IETF はプロトコルパラメータのレジストリを頻繁に作成する。RFC 8126は、それらのレジストリで値を割り当てるための専門家レビュー、仕様要求、標準アクションなどのポリシーを説明する。IANA 機能は結果のテーブルを管理できる。
これらのプロトコルレジストリは仕様内の名前空間問題を解決する。コードポイントは2つの互換性のないものを意味してはならない。レビューアは割り当てが技術的基準に適合するかどうかを判断できる。それは、誰が IPv4 ブロックや ASN に永続的な利益を有するかを決定することとは異なる。
NRS は独自の制御語彙を必要とする：イベントタイプ、ステータス値、証拠クラス、プロファイルバージョン、拡張識別子。透明な割り当て、衝突回避、レビューア条件、異議申し立てのために RFC 8126を設計ガイダンスとして使用できる。同じ専門家レビューモデルが事業者の権利を決定できると推測すべきではない。
指定された専門家は、拡張が相互運用可能かどうかを判断する資格があるかもしれない。専門家は事業者が登録認識を失うかどうかを判断すべきではない。前者は狭い技術的割り当てであり、後者は不利な制度的行為である。
境界は IANA も保護する。プロトコルパラメータ機能は、メッセージにエンコードされたすべての商業的または法的請求を検証するよう求められることなく、中立な技術サービスであり続けることができる。NRS は共有レジストリを使用して実装の互換性を維持しつつ、理由、証拠、救済が利用可能な場所で権利の裁定を維持すべきである。
特許およびライセンスリスクは可搬性分析に属する
オープンな公開プロセスは、すべての実装が知的財産リスクから自由であることを保証しない。IETF 手続きは定義された条件下で既知の権利の開示を要求するが、開示は完全な特許検索や普遍的なライセンスではない。
NRS は、明確で非差別的な条件の下で複数のプロバイダが実装できるプロファイルを優先すべきである。1つのベンダーによって制御されたり、不確かなライセンスによって妨げられたりする必須コンポーネントは、オープン標準を経済的ロックインに変える可能性がある。
採用レビューは、誰が必須コード、特許、テストツール、スキーマ、商標を所有しているか、後継者が同じ権利を取得できるか、オープンソースとプロプライエタリの両方の実装が実用的か、ライセンスが撤回された場合に何が起こるかを尋ねるべきである。回答は出口影響声明の一部であるべきである。
これは NRS のすべてのコンポーネントがフリーソフトウェアであることを要求するものではない。独立した実装は異なるライセンスモデルを使用できる。憲法上の要件は代替可能性である。事業者は、紛争中に唯一の適合する代替品が現職プロバイダからの許可に依存していることを発見すべきではない。
リスクが不確かな場合、NRS はコンポーネントをインターフェースの背後に隔離し、代替実装パスを保存し、独自フォーマットに置き換え不可能な歴史的状態を置かないようにできる。標準の採用はスイッチングコストを下げるべきである。もしスイッチングコストを上げるなら、正当化の負担もそれに伴って上がる。
拡張は自身の出口コストを負担しなければならない
成功した技術プラットフォームはすべて拡張を蓄積する。一部はローカルニーズを解決し、他のものはプロバイダの内部モデルをいわゆる共通標準に忍び込ませる。NRS は実験を許可しつつ、拡張が私的な関所にならないようにすべきである。
ベースプロファイルには、すべての資格のあるプロバイダが権威ある状態と継続性を維持するために必要なもののみを含めるべきである。オプションの拡張は名前空間化され、文書化され、安全性が許す限り無視可能であるべきである。拡張が後に必須になった場合、独立した実装、移行、権利審査を通過すべきである。
不利なアクション、保有者ステータス、または資格情報制御に影響する拡張はメタデータとして却下できない。それは権威の表面を変更し、契約レビューに属する。単に分析を改善するだけの拡張は、登録認識の条件になるべきではない。
エクスポートは、受信プロバイダに実行を強制することなく、未知の拡張を保存しなければならない。歴史的証拠は署名付きマテリアルとして移動でき、後継者は理解されたセマンティクスのみをマッピングする。拡張を安全に保存できない場合、事業者は採用する前に知るべきである。
この規律は革新をエッジに保ち、共通層を薄く保つ。また、NRS 自身の製品を争えるようにする。有用なプレミアムサービスは価値で競争できるが、事業者のコア記録はベースプロファイルを通じて可搬のままでなければならない。
適合はイデオロギー的な認証になってはならない
NRS は適合テストを必要とし、ロイヤルティバッジではない。プロバイダは、プロファイルを実装し、鍵を保護し、一意性を維持し、状態をエクスポートし、復旧テストに合格し、権利スケジュールを受け入れるために資格を得るべきである。NRS のすべての政治的声明を支持する必要はない。
テスト範囲は公開されるべきである。結果はテストされたバージョン、日付、環境、評価者、制限事項を特定すべきである。失敗は定義された是正パスにつながるべきである。停止は失敗した機能に比例すべきであり、オプションの分析サービスにおける欠陥は権威ある登録を無効にすべきではない。
認証機関自体がゲートキーパーになり得る。NRS は同じスイートを使用する複数の有能な評価者を許可し、レビューアをローテーションし、利害の衝突を開示し、異議申し立てを許可すべきである。自己テストは開発をサポートできるが、高い結果の資格には独立した証拠が必要である。
事業者は、プロバイダが移行テストに合格したかどうか、単に通常のサービスに合格したかどうかだけでなく、確認できるべきである。新しい記録を受け入れられるが、既存の記録を引き渡せないプロバイダは、可搬可能なレジストリモデルに適合していない。
イデオロギー的中立性は行動への無関心を意味しない。詐欺、偽造された権限、あいまいな態度、可搬状態の返却拒否は、共通サービスを直接脅かす。それらは名前付きルールの下でテストされ、制裁され得る。これらの機能に関係のない政治的意見の相違は、技術的失敗に変換できない。
出口はサービス層で行使されなければならず、一意性のフォークではない
実用的な出口権は、2つの権威あるプロバイダが同じリソースに矛盾する変更を加えることを意味しない。それは制度的ロックインを重複した真実に置き換えることになる。NRS は1つの有効な状態を保存する移行プロトコルを必要とする。
シーケンスには、事業者リクエスト、制御検証、現在のプロバイダへの通知、係争中の紛争の特定、最終状態コミットメント、受信プロバイダの確認、資格情報の移行、ディスカバリ更新、読み取り継続のための限定オーバーラップ、最終カットオーバーを含むべきである。各ステップは両方のプロバイダと事業者が保持できる証拠を生成すべきである。
現在のプロバイダは裁量的な拒否権を持つべきではない。定義された不正懸念、裁判所命令、制裁制限、未解決の請求を提示できる。中立的な審査者がその問題が移動を停止するか、狭めるか、許可するかを決定する。紛争は記録とともに移動し、可搬性が逃避にならないようにする。
オープン標準はこのシーケンスを再現可能にする。契約はそれを受け入れたプロバイダに対して性能を強制可能にする。独立したテストは代替がそれを実行できることを証明する。これらの要素のいずれも単独では十分ではない。
出口権は NRS 自身にも適用される。事業者は、有効な記録や資格情報を失うことなく NRS サービスから離れることができるべきである。可搬性を説きながら自己の地位を不可欠にする協会は、改革を継承に変えている。
契約はオープンインターネットの敵ではない
インターネット文化は時に契約を、オープンな技術調整に反対する私的制約として扱う。レジストリガバナンスにおいて、明確な契約は制度的権力に対する規律となり得る。それは当事者、サービス、権利、義務、責任、修正ルール、期間、出口、救済を特定する。
代替手段はしばしば自由ではない。それは、未定義のコミュニティによって開発されたポリシーが、レジストリを使用するという理由だけでアカウント保有者を拘束するという不明確な主張である。その主張は正確な条項よりも検査や異議申し立てが難しい。
NRS 契約は技術プロファイルをバージョンごとに組み込みつつ、権利スケジュールを安定に保つべきである。どの変更に事業者の同意が必要か、どの変更が通知で済むか、どの変更が緊急セキュリティに対処するかを指定すべきである。目的、証拠収集、不利なアクション権限の重要な拡大は、日常的な技術更新を通じて到着すべきではない。
契約は該当する法律も保存すべきである。NRS は裁判所、規制当局、制裁義務からの免除を約束できない。権限を特定し、要求より広い行動を避け、合法的な範囲で事業者に通知し、可能な限り審査と移行を保存することを約束できる。
最も重要なのは、契約は出口と組み合わされなければならないことである。独占によって提示された「それを受け入れるか番号を再割り当てするか」の契約は、同意ではなく依存を形式化できる。オープンインターフェースとプロバイダの可搬性こそが、明確な条件を意味ある選択に変える。
NRS は信頼される前に自らを代替可能にすべき
制度的信頼性は通常、長年の運用の後に到着する。これは新しいサービスにとってパラドックスを生み出す。事業者はテストされていない継続性に依存しないが、ユーザーなしでは継続性をテストできない。NRS は最初に代替可能性を証明することでサイクルを断ち切れる。
重要な状態を制御する前に、ベースプロファイル、権利スケジュール、テストスイート、移行手順を公開できる。2つの独立したデモンストレーションプロバイダが合成記録を交換し、鍵をローテーションし、エラーを訂正し、敵対的な出口シナリオを完了できる。監査人は保持された証拠から決定を再構築できる。事業者はカットオーバー前に非権威的なミラーまたはレシートで参加できる。
デモンストレーションには NRS 自身の失敗を含めるべきである。別のプロバイダが必要な状態を回復できるか？事業者は自分たちの記録が含まれていることを確認できるか？依拠サービスは後継者を発見できるか？係争中の紛争は可視のままか？侵害された鍵を無言の履歴変更なしで交換できるか？
これらの演習はソフトウェア以上のものを証明する。それらは、機関が自分自身を標準に設計していないことを証明する。成功した継承テストは、NRS の権威が依然としてサービスに由来する証拠である。
ライブ採用が始まると、権威は機能ごとに拡大すべきである。読み取り専用検証は書き込み権限に先行できる。任意の可搬性パイロットは一般サービスに先行できる。制限、ロールバック、独立した観察は明示的にすべきである。NRS は決して最初に認知を要求し、後で証拠を約束すべきではない。
IETF との関係は公開、技術的、非排他的であるべき
NRS は関連する IETF 作業に実装者および運用者として参加すべきであり、特権的地位の請求者としてではない。相互運用性の発見を提出し、曖昧さを報告し、拡張を提案し、セキュリティ分析を提供できる。その証拠は他の参加者からの証拠と品質で競争すべきである。
関係は両方向で非排他的であるべきである。NRS は他のオープン団体からの適切な標準を採用するか、標準が適合しない場合に公開プロファイルを開発できる。IETF は現職レジストリ、ベンダー、他の運用者と協力でき、それらのいずれにも制度的優先権を与えない。
連絡窓口を使用する場合、狭い範囲、公開された出力、事業者の権利を交渉する権限がないべきである。IETF リーダーの参加は承認として宣伝されるべきではない。NRS 実装への RFC 参照は、主権の承認ではなく技術文書として扱われるべきである。
この姿勢は IETF に利益をもたらす。標準議論はインターフェースと運用証拠に集中し続け、番号リソースの制御をめぐる代理戦闘にならない。NRS に利益をもたらすのは、協会が後援に依存できなくなるからである。事業者にとっては、隠された政治的和解を受け入れずに技術的結果を使用できるからである。
適切な文は単純である：NRS はこの仕様を実装し、相互運用を実証した。それより強いものは異なる権威の源泉を必要とする。
限定的な NRS-IETF 規約
関係は10のコミットメントで表現できる。
NRS は一般的に RFC シリーズを呼び出すのではなく、正確な技術仕様を特定する。プロトコル適合性とリソース権利を区別する。コアの可搬機能に独立した実装を要求する。テスト範囲、失敗、バージョン移行を公開する。運用者の経験をプロファイルを変更できる証拠として扱う。
標準の更新が自動的に権利を修正することを許可しない。通知、審査、停止、訂正、出口を別個の契約に置く。拡張を可搬に保ち、単一ベンダー依存を避ける。IETF の承認を主張せずに技術的発見を提供する。継承をリハーサルし、自身の失敗が事業者を閉じ込めないようにする。
IETF は見返りに特別な何も約束する必要はない。既存の公開プロセスと仕様は実装者が利用できる。NRS は他の誰と同じ審査を受け入れるべきであり、運用を通じて価値を実証すべきである。
規約は意図的に非対称である。標準化団体は各採用者を祝福する必要はない。採用者は標準に付随する制度的結果に対して責任を負う。NRS の正当性は、その責任を世界的な名前を借りるのではなく明示的にするときに成長する。
成功は宣言ではなく証拠によってどのように見えるか
最初の指標は相互運用性である。独立したクライアントとプロバイダが同じプロファイルの下で完全な記録を交換し、セマンティクスを保存し、障害を一貫して処理する。2つ目は可搬性である。事業者は公開された時間内に資格のあるプロバイダを変更し、グローバルな一意性、履歴、アクティブなセキュリティ状態が無傷のままである。
3つ目は権利のパフォーマンスである。通知は結果的な行動の前に到着し、理由は証拠と権限を特定し、審査者はエラーを停止でき、訂正は可視のアカウントを追加し、有効な紛争はルーティング停止にならない。4つ目は制度的抑制である。NRS は管理には有用だが狭いサービスには不要な提案を拒否する。
5つ目は市場の代替可能性である。複数のプロバイダが NRS の好みのベンダーの許可なしにベースプロファイルを実装できる。スイッチングコストは時間とともに低下する。拡張はインストールベースの圧力だけで必須にならない。
6つ目は捕捉なき標準参加である。NRS は実装レポートを提出し、技術的批判を受け入れる。RFC を承認として扱うことも、契約の好みを非参加者を拘束するプロトコル要件に変えようとすることもしない。
これらの指標は可視的に失敗し得る。それは強みである。成功を認知、会員、出版としてのみ定義する機関は、事業者を保護せずに勝利を宣言できる。相互運用、継続性、出口によって判断される機関は、その目的を証明し続けなければならない。
オープンプロトコルは権力を離れやすくすべき
NRS の最も強い主張は、すべての現職よりも良いルールを書けることではない。それはルールと依存の関係を変えられることである。オープン技術標準は記録をプロバイダ間で理解可能にできる。独立した実装は主張を再現可能にできる。運用証拠は事業者を失敗させる設計を暴露できる。契約は権利と救済を明記できる。出口はそれらの約束すべてを儀式的にしないようにできる。
IETF はこのモデルにおいて、憲法上の上位者ではなく技術的作業の源泉として属する。その最良の標準は独立したシステムに相互運用方法を伝える。自身の使命声明は、出版が使用を義務付けることを否定する。その謙虚さは、標準が番号ガバナンスに達するときに保存されるべきである。
NRS も同様に謙虚であるべきである。正確な状態を維持し、権限を検証し、必要な技術サービスをサポートし、継続性を保護すべきである。暗号、RFC 引用、尊敬されるエンジニアの参加から政治的主権を推測すべきではない。その権利ルールは執行可能で、離れるのに十分狭いように明示的であるべきである。
結果は標準なき権威ではない。それは適切な手段に割り当てられた権威である。プロトコル著者は適合性を定義する。事業者とプロバイダはサービスを契約する。裁判所と公法は法的義務を扱う。ネットワークはルーティング決定を行う。NRS はこれらのアクターが必要とする最小限の状態を調整し、それらすべてになろうと主張しない。
オープン標準は、実施機関を代替可能にするときに最高の制度的価値に達する。NRS がその命題を証明できれば、IETF 技術以上のものを採用したことになる。相互運用可能な技術を主権に対する防御にした抑制を回復したことになる。
証拠と分析の限界
NRS 憲章は、協会の表明された方向性を支持している：正確な登録、制限された簿記役割、任意の認識、企業の自由、透明性、説明責任。NRS の公開された使命は、登録管理と制度的集中の低減に対する事業者中心の強調を支持している。これらは建設的な方向性を定義するためのファーストパーティの立場であり、展開された可搬性、IANA 認識、独立した実装、普遍的な事業者サポートを証明するものではない。
Lu Heng のランニングコード優位の分析は、最小限の共通ルール、ローカル検証、任意採用、事業者選択が制度的プロセスよりも優先されるべきという規範的枠組みを提供している。その主張は表明されたガバナンスの立場である。この記事の具体的な NRS 規約、採用ファイアウォール、テストシーケンスは設計提案である。
RFC 3935は、相互運用性、プロトコル所有権、IETF の採用義務付けや監視拒否の説明を支持している。RFC 2026とRFC 6410は、独立した実装、展開、運用経験の役割を支持している。これらは標準システムに関する IETF の声明であり、NRS の権限の付与としてではなく、技術的および制度的証拠として使用されている。
RFC 9082、RFC 9083、RFC 9084、RFC 6480、RFC 4271、RFC 8126、RFC 2119、RFC 8174は、限定された技術例を支持している。いずれも所有権、契約上の権利、法的権原、または NRS の権威あるレジストリプロバイダとしての承認を決定するものではない。
RFC 7020は、インターネット番号の非ポリシー技術的側面に対する IETF の責任とレジストリ機関におけるポリシー開発との区別を支持している。それは既存の制度的取り決めを説明している。その取り決めが永久的、代表的、または十分であるという証明として扱われていない。