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