概況

  • このテーマにおける NRS の役割は、アドボカシー、研究、キャンペーン、協議、および権限を与えられた会員の代表です。運用行為は RIR、その契約事業者、影響を受けるホルダー、ネットワーク事業者、独立監査人に属します。NRS の見解を引用することは、NRS がそれらを実行しているという証拠でも、BTW による推奨でもありません。
  • レジストリサービスレベルは、ホルダーが検証できる状態を記述すべきであり、機関がカウントできる活動を記述すべきではありません。チケットの受付確認、プラットフォームの可用性、平均応答時間は依然として有用な診断指標ですが、公的登録記録が正確であることや制御が回復されたことを証明するものはありません。
  • 5 つのカスタマージャーニーには個別のコミットメントが必要です：記録の正確性維持、申告されたエラーの訂正、許可された移転の完了、RPKI および関連権限の安全なハンドオフ、侵害またはプロバイダ障害からの復旧。1 つの一般的なサポート目標では、それぞれの異なるリスクを代表することはできません。
  • すべてのクロックには、観測可能な開始、許可される一時停止の狭いリスト、最大一時停止期間、および結果ベースの停止が必要です。レジストリ事業者は、不足している事実とその必要性を特定せずに提出を不完全と繰り返し宣言することにより、プロバイダが開始を遅延させるのを防ぐべきです。
  • 正確性は、依拠表面で測定されなければなりません。あるプライベートシステム内の正しい値は、権威ある RDAP、委任ファイル、逆 DNS 権限、または RPKI サービス状態が依然として古いまたは矛盾した結果を提示している場合、コミットメントを満たしません。
  • 移転と証明書ハンドオフは結合されていますが同一ではありません。ホルダーは、1 つの順序付けられた登録変更、必須のセキュリティ権限の継続性、以前のプロバイダの管理の終了、および 2 つの互換性のない現状を許容せずに各移行を証明するのに十分な証拠を受け取らなければなりません。
  • パフォーマンスレポートは、パーセンタイル、経過案件、重大度、コホート、除外、再開、および顧客確認結果までの時間を開示すべきです。平均および可用性パーセンテージは、番号リソースへの依存が遅延を運用上の害に変える小さなテールを隠す可能性があります。
  • コミットメントの未達には結果が必要です：定義された遅延に対する自動料金クレジット、訂正費用の払い戻し、独立したレビュー、反復障害の是正、および証明可能な損失に対する別途の補償制度へのアクセス。救済手段のないサービスレベルは、管理的な願望に留まります。

役割の境界は証拠の一部である

NRS 自身が表明するポジショニングは、この分析の最初の境界を提供します。NRS は、分散化、退出、ポータビリティ、冗長性、およびより少ない裁量的なチョークポイントを求める会員制およびアドボカシー組織です。Lu Heng による NRS の存在理由に関するノートは、NRS が製品を販売したり商業ソリューションを実装したりせず、その役割はガバナンスの方向性を変えることであると直接述べています。したがって、NRS は研究を発表し、キャンペーンを組織し、影響を受ける事業者を招集し、会員を支援し、権限を与えた組織を代表することができます。NRS は、その代表を他の誰かに対するレジストリ権限に変えることはできません。

実装層は別です。RIR、その契約事業者、影響を受けるホルダー、ネットワーク事業者、独立監査人は、この記事に関連する権威あるレジストリ記録、割り当て、移転認識、RPKI または RDAP 運用、技術的フェイルオーバー、拘束力のあるレビュー、破産行為、または法的に強制された救済に対して責任を負い続けます。NRO は 5 つの RIR を調整します。NRS の別名ではありません。IANA 番号サービスは定義された調整役割を実行します。NRS の部門ではありません。裁判所および合法の公的当局は、その法制度が実際に与える権限を保持します。

BTW の役割はさらに別です。BTW は観測可能な構造を報告し、一次情報源を確認し、提案を提案としてラベル付けします。NRS のアドボカシーを事実に変換したり、NRS に代わってキャンペーンを行ったり、整合性から権限を推測したりしません。現実であってアドボカシーではないというこの規律が、この記事の制度名詞が重要である理由です：NRS からの推奨、RIR による行為、裁判所からの命令は、3 つの異なるものです。

顧客はダッシュボードを消費しない

運用チームにはダッシュボードが必要です。データベースが複製されているか、認証が応答しているか、到着したリクエストの数、成長しているキュー、利用できない依存関係を知る必要があります。これらの測定は、ホルダーが気付く前に問題を特定できます。誤りは、機関が同じ測定値を、顧客が約束されたサービスを受け取った証拠として提示するときに始まります。

合併後に法的名称が更新されたホルダーを考えてみてください。提出は受理され、ケース管理画面は完了を記録します。プライベートアカウントビューは新しい名前を示します。権威ある RDAP は、公開コンポーネントが故障したため、4 日間、以前の会社を表示し続けます。スタッフの観点からは、ケースはクローズされ、ほぼすべてのシステムが正常です。顧客の観点からは、取引相手が使用する記録は依然として間違っています。

この違いは意味的なものではありません。インターネット番号記録は、デューデリジェンス、虐待連絡先、移転チェック、ルーティングセキュリティ管理、運用上の信頼に影響を与えます。RFC 7020は、登録の正確性と一意性をインターネット番号レジストリシステムの中核目標として扱います。したがって、正確性は、機関が目的の値をどこかに保存したという理由だけで達成されるわけではありません。権威あるサービスが、正しい現在の状態を、一貫した補足権限とともに、それに依拠する権利のある者に提示するときに達成されます。

レジストリサービス事業者のコミットメントは、「ホルダーは～できる」という文で始めるべきです。ホルダーは、受理された訂正を権威ある RDAP で見ることができる。ホルダーは、移転が 1 つの現在のプロバイダに達したことを証明できる。ホルダーは、証明書ハンドオフ後に有効なルーティング認証を発行および管理できる。ホルダーは、通常の資格情報が利用できない場合に、テストされた経路を通じて権限を回復できる。これらの文は、メトリクスがサービスを記述しているのか、管理のみを記述しているのかを明らかにします。

可用性は必要だが、根本的に不完全である

可用性は、サービスが応答するかどうかを測定します。必ずしも、応答が正確、最新、承認済み、または有用であるかを測定するわけではありません。RDAP エンドポイントは、インシデント全体を通じて HTTP 応答を返しながら、古いホルダー、廃止されたステータス、不完全なイベント履歴を提供することができます。ポータルは、完了基準のないキューにリクエストを配置しながら、リクエストを受け付けることができます。証明書リポジトリは到達可能でありながら、ホルダーが ROA を更新するために必要な資格情報に対する実用的な制御を失っている可能性があります。

この区別は、他のインフラ分野ではよく知られています。支払いサービスはオンラインであっても、特定の顧客の資金にアクセスできないことがあります。鉄道はほとんどの列車を運行しながら、1 人の乗客の旅が失敗することがあります。クラウドコンソールは読み込まれても、保護されたアカウントの復旧が不可能なことがあります。可用性は、配信の 1 つの状態を記述するものであり、結果全体ではありません。

レジストリ事業者は、権威ある RDAP、登録変更提出、検証、RPKI 公開、緊急連絡チャネルについて、技術的可用性のコミットメントを維持すべきです。可用性がどのように測定されるか、どの独立した視点から、どのようなメンテナンス除外があるかを公開すべきです。しかし、各技術的測定値は、顧客結果のコミットメントの下に位置づけられるべきです。障害は、結果を逃した理由を説明するかもしれませんが、結果を成功と再定義するべきではありません。

同じ階層がサポート指標にも適用されます。最初の応答までの時間は、沈黙が不確実性を高めるため有用です。しかし、迅速な自動確認は、間違った記録を訂正しません。処理されたケース数は作業負荷を示すかもしれませんが、不要な交換を促進する可能性があります。顧客満足度はコミュニケーションの失敗を明らかにするかもしれませんが、一意性やセキュリティを検証することはできません。レジストリ事業者は、これらすべての手段を必要とします。それらのいずれかが、完了した正確で安全なサービスの代わりとなることを許すべきではありません。

サービスレベルには 5 つの文法的要素が必要である

防御可能なコミットメントには、範囲、開始、結果、期限、結果の 5 つの部分があります。範囲は、対象となるカスタマージャーニーと条件を特定します。開始は、利用可能なチャネルを通じた署名付きリクエストの受領など、両当事者が証明できるイベントです。結果は、観測可能な最終状態を記述します。期限は、経過時間または明確に定義されたサービスカレンダーを指定します。結果は、コミットメントが逃された場合に何が起こるかを述べます。

曖昧な言葉は通常、少なくとも 1 つの部分を省略します。「迅速に対応するよう努めます」には結果も期限もありません。「ほとんどの変更は 2 日以内に処理されます」は、カウントがいつ始まるか、処理済みの意味、除外された変更、残りの変更に何が起こるかを述べていません。「プラットフォームは 99.99% の可用性を達成しました」は、訂正について何も述べていません。「複雑なケースは時間がかかることがあります」は、プロバイダが管理するラベルの下で無制限の一時停止を与えます。

レジストリ事業者は、平易な言語と機械可読なイベント定義でサービスレベルカタログを公開すべきです。カタログは、標準的なリクエストと、争いのあるホルダー変更、制裁制限、進行中の裁判所命令、疑わしい詐欺を区別すべきです。標準的なケースは、訴訟のスケジュールを継承すべきではありません。争いのあるケースは、通常の遅延として偽装されるべきではありません。分類の決定は、記録され、通知され、レビュー可能であるべきです。なぜなら、分類がクロックを決定するからです。

カタログはまた、誰のパフォーマンスが測定されているかを述べるべきです。リテールレジストラがリクエストを受け取り、共通バリデータが状態をコミットし、RPKI 事業者が証明書移行を実行し、RDAP パブリッシャーが結果を公開することがあります。ホルダーは、複数の機関が寄与する場合でも、1 つのエンドツーエンドのコミットメントを受け取るべきです。プロバイダ間の責任の割り当ては、その約束の背後にあるべきであり、顧客がチェーンを診断する理由になるべきではありません。

記録の正確性は、チケットカテゴリではなく、維持される状態である

最初のサービスレベルは、継続的な正確性に関するものです。更新リクエストの速度よりも広い概念です。レジストリ事業者は、正確でなければならない権威あるフィールドと状態遷移を定義すべきです：認識されたホルダー ID、公開または開示が許可された連絡先または役割データ、リソース範囲、現在のステータス、登録日、サービスプロバイダ照会、移転状態、関連する登録イベントへのリンク。保護された証拠を公開せずに、どの値が公開、制限、または派生かを特定すべきです。

RFC 9083は、インターネット番号およびその他の登録データに対して RDAP で使用される JSON 応答を定義します。そのイベント構造、エンティティ、通知、リンクにより、裸の連絡先行よりも豊かな現在状態の説明が可能になります。その技術的語彙は制度的権利を決定するものではありませんが、正確性をテストできる表面をレジストリ事業者に提供します。同じ現在の事実は、明示的な理由とタイムスタンプなしに、権威あるビュー間で異なって現れるべきではありません。

正確性のコミットメントには、積極的な管理が必要です。受理された変更は、公開後に公的依拠表面に対してチェックされるべきです。レプリカは、乖離について比較されるべきです。高リスクの変更は、事前に確立されたチャネルを通じてホルダーに独立した確認を受けるべきです。古い状態には最大年齢が設定されるべきです。矛盾する現在の状態は、顧客がまだ苦情を申し立てていなくても、重大度分類をトリガーするべきです。

レジストリ事業者は、すべての履歴記述が論争のないものであることを約束すべきではありません。過去の割り当て、合併、破産、古いスポンサーシップ関係には、不完全な証拠が含まれる可能性があります。約束は正確であるべきです：レジストリ事業者は既知の履歴を保存し、真の不確実性をマークし、未解決の主張を確定した事実として提示せず、訂正への限定的な経路を提供します。正確性には正直な限定が含まれます。証拠が裏付けられない確実性を製造することをレジストリに要求するものではありません。

したがって、測定可能な結果は多面的です。受理された現在の値は、すべての権威ある依拠表面に現れなければなりません。互換性のない現在の値がアクティブであってはなりません。イベント履歴は、変更がいつ有効になったかを特定しなければなりません。依存する権限は、現在のホルダーまたはその許可行列者に対応しなければなりません。ホルダーは、何が変更され、どこで表示され、エラーに挑戦する方法を特定する確認を受け取らなければなりません。そのときにのみ、正確性のクロックは停止すべきです。

訂正には最終判断の前の封じ込めが必要である

報告されたエラーは、2 つの異なる義務を生み出します。第一は、潜在的に間違った状態への予見可能な依拠を封じ込めることです。第二は、正しい状態を決定し公開することです。第一はしばしば迅速に行えますが、第二は複数の関係者からの証拠を必要とする場合があります。単一の最終解決目標は、機関が危険な主張を長期間未マークのままにするか、単にクロックを止めるために時期尚早な決定を下すことを奨励します。

レジストリ事業者は、段階的な訂正コミットメントを使用すべきです。申し立てを確認し、争われた状態を保存すべきです。初期の権限と重大度評価を実行すべきです。申し立てが信頼でき、潜在的な害が重要である場合、レビュー中に中立的なステータス注釈を追加するか、高リスクの変更を制限すべきです。各関係者から必要な証拠を特定し、理由を付けて問題を決定し、訂正または限定された状態を公開し、伝播を確認すべきです。

封じ込めステップは慎重に制限されなければなりません。申立人は、主張をするだけで無関係なホルダーを凍結できるべきではありません。初期措置は、認証された立場、具体的な矛盾する証拠、侵害の兆候、またはレジストリ事業者自身によって作成された不一致に依存すべきです。注釈は必要な以上に述べるべきではありません。調査結果が存在する前に不正行為を暗示すべきではなく、定義された時間で期限切れになるかレビューされるべきです。

訂正クロックは、スタッフが決定メールを送信したときに停止すべきではありません。権威ある状態が訂正または適切に限定され、矛盾する依存権限が解決され、顧客が完了の証拠を受け取ったときに停止すべきです。申し立てが却下された場合、結果には理由のある通知と一時的な制限の解除が含まれるべきです。再開されたケースは報告されるべきです。なぜなら、頻繁な再開は名目上のクロージャーが信頼できないことの証拠だからです。

提出の負担は保管に従うべきです。ホルダーは、その保有する企業権限、取引文書、または ID の証明を合理的に求められることがあります。レジストリ事業者は、レジストリ事業者またはその前身が保存する責任を負っていた記録をホルダーが再作成することを要求すべきではありません。機関の証拠の欠如は、自動的に顧客に不利に働くわけではありません。サービスレベル報告は、プロバイダ保有、顧客保有、第三者保有の証拠によって引き起こされる遅延を個別に特定すべきであり、すべての一時停止を申請者に割り当てるべきではありません。

移転は、権限が一度移動したときにのみ完了する

ポータブルな登録制度は、移転コミットメントに依存します。最大時間と客観的な完了状態がなければ、現職者は退出の権利を正式に受け入れながら、遅延を通じて独占を維持することができます。レジストリ事業者は、サービスプロバイダの変更と、リソースの売却、合併、ホルダーの変更、争いのある承継を区別すべきです。各イベントは異なる証拠を持ちます。プロバイダの切り替えは、ホルダーの指示とは無関係なタイトルのようなレビューを強制されるべきではありません。

移転は、取得プロバイダが定義された最小データを含む認証されたホルダー指示を提出したときに開始します。共通バリデータは、迅速に十分性を確認すべきです。喪失プロバイダは、狭い異議を特定することができます：資格情報の侵害の証拠、進行中の法的制約、矛盾するホルダー変更リクエスト、またはそのような料金が許可されている場合の移転サービスに直接関連する特定の未払い料金。一般的な不満、無関係な債務、沈黙は拒否権であってはなりません。

完了には、1 つの順序付けられたコミットが必要です。共通状態は、取得プロバイダを現在として指名し、喪失プロバイダの現在の権限を終了し、イベント履歴を保存し、新しい状態を権威ある RDAP を通じて公開しなければなりません。通知は、確立されたチャネルを通じてホルダーと両プロバイダに送られるべきです。アトミックに移動できない依存サービスは、1 つの権威ある方向と矛盾する現在の指示なしに、定義された短期間の移行に入るべきです。

レジストリ事業者は、ホルダー指示から顧客確認可能な完了までの移転期間を報告すべきであり、バリデータで費やされた時間だけではありません。目標内で完了した割合、中央値、上位パーセンタイル、最も古い未解決ケース、理由コード化された一時停止、現職者の異議、却下された異議、移転後の訂正を示すべきです。報告は、通常のプロバイダ切り替えをホルダー変更や法的紛争から分離すべきです。そうでなければ、少数の困難なケースが遅い通常サービスを正当化するために呼び出され、通常のボリュームが深刻なテール障害を隠す可能性があります。

失敗した移転は、謝罪以上のものを生み出すべきです。ホルダーは、回避可能な遅延に対する料金クレジット、ミスによって引き起こされた合理的な重複サービス料金の払い戻し、および以前のプロバイダが退出を妨害したように見える場合の迅速な独立レビューを受けるべきです。繰り返される妨害は、プロバイダの資格に影響を与えるべきです。ポータビリティは、現職者が退出を使用不可能にすることに対する結果を負うときに現実のものとなります。

証明書ハンドオフは、添付物ではなくセキュリティの結果である

RPKI は、別の権限表面を追加します。番号ホルダーは、ホスト型サービスに依存して証明書機関機能を管理し、Route Origin Authorization を公開することがあります。登録関係を移動しても、これらの制御は自動的に移動しません。古いプロバイダが移転後も行動できる場合、または新しいプロバイダが古いチェーンが終了する前に有効な権限を確立できない場合、顧客は矛盾する認証または回避可能なギャップに直面する可能性があります。

RFC 6480は、Resource Public Key Infrastructure と、インターネット番号リソースの保有に関する証明をサポートするその目的を記述しています。RFC 6492は、親子証明書機関間のプロビジョニングプロトコルを指定します。これらの標準は技術的メカニズムを確立しますが、プロバイダ変更の商業的責任を自動的に割り当てるものではありません。レジストリ事業者は、サービスコミットメントを追加しなければなりません。

顧客結果は、1 つの運用モデルを仮定せずに述べられるべきです。ハンドオフ後、現在のホルダーまたはその許可行列者は、新しい権限体制の下で有効なルーティング認証を管理できなければなりません。意図された ROA は、ホルダーが計画された撤回を明示的に選択しない限り、継続的に利用可能でなければなりません。以前のプロバイダは、新しい顧客向けの変更を行う能力を失わなければなりません。公開ポイント、マニフェスト、失効状態は、設計どおりに収束しなければなりません。独立した依拠当事者の観察は、意図しない無効または矛盾する状態が作成されなかったことを検証すべきです。

ハンドオフ計画は、登録コミットの前に生成され、ホルダーと確認されるべきです。現在の認証、移転後の意図されたセット、証明書とリポジトリの依存関係、新しい発行と古い廃止の順序、監視視点、ロールバック境界、緊急連絡先をリストするべきです。秘密鍵素材は、単に便宜のために軽率に転送されるべきではありません。新しい権限関係は、適用可能な標準メカニズムを使用して確立できます。サービスレベルは、特定のファイルの移動ではなく、許可された効果の継続性を測定します。

一部の移行は重複を必要とします。重複は、2 つのサービスプロバイダが互換性のない指示を公開する無制限の力を持たないように、狭く設計されるべきです。レジストリ事業者は、各段階でどのプロバイダが行動できるか、どの変更が凍結されるか、緊急時の撤回方法、最大重複期間を定義すべきです。ハンドオフクロックは、ホルダーが新しい権限を行使でき、意図された公開状態が独立した視点から検証され、以前のプロバイダの変更権限が廃止された後にのみ停止します。

復旧は、回復された制御によって測定される

復旧は、侵害された資格情報、失われた認証子、プロバイダの停止、レジストラの破産、バリデータの障害、誤ったロックアウトをカバーします。各イベントはチェーンの異なる部分を脅かしますが、顧客は同じ実用的な質問をします：依存関係が停止になる前に、正当な代表者がどのように安全に制御を再取得できるか？

レジストリ事業者は、障害の前に確立された復旧経路を要求すべきです。ホルダーは、複数の権限者、安全な帯域外チャネル、緊急企業証明セットを登録すべきです。設計は、退職した従業員を恒久的な復旧ゲートにすることなく、スタッフの変更をサポートすべきです。高リスクの復旧は、遅延が乗っ取りリスクを低減する場合には、複数の独立したチェックと遅延通知を使用すべきですが、緊急封じ込め経路は積極的な侵害から保護します。

サービスコミットメントは、封じ込め、暫定継続、完全復旧を区別すべきです。封じ込めは、不正な変更を凍結し、現在のルーティングセキュリティ状態を保存できます。暫定継続は、厳しく制限された権限の下で必須の公開および連絡機能を維持できます。完全復旧は、検証された代表者に通常の制御を戻し、侵害された資格情報を交換し、インシデント中に行われた変更をレビューし、結果として生じる登録および RPKI 状態を確認します。

プロバイダ自身の障害は、コミットメントを停止すべきではありません。資格のあるレジストラおよび共通サービスは、エクスポート可能で暗号化された継続性素材とテストされた後任者配置を維持すべきです。ホルダーは、復旧を呼び出すために障害のあるプロバイダの通常のポータルにアクセスする必要はありません。レジストリ事業者は、プロバイダの喪失、上級署名者の不在、レプリカ間の不一致を含む現実的な演習で復旧をテストすべきです。実行されたことのない文書は、顧客が復旧できることの証拠ではありません。

復旧時間は、重大度と開始条件によって報告されるべきです。忘れたパスワードは、権限のある代表者の侵害やプロバイダの崩壊とは比較できません。しかし、分類が無制限の遅延の言い訳になってはなりません。すべてのクラスには、封じ込めまでの最大時間、理由のある復旧計画までの最大時間、および上級独立レビューが自動的になる前の最大経過時間が必要です。

クロックはプロバイダだけに属してはならない

サービスコミットメントは、クロックを操作することによって紙上で改善するのは簡単です。プロバイダは、ケースが「完了」したときのみ時間が始まると言い、一度に 1 つの質問をし、回答ごとにクロックをリセットし、週末を不可視として分類し、新しい参照の下でケースをクローズして再開することができます。レジストリ事業者は、どちらの側もパフォーマンスを操作できないようにクロックを定義すべきです。

受領は、独立して監査可能なサービスによってタイムスタンプされるべきです。短い十分性期間内に、責任のあるプロバイダは、提出を受け入れるか、または各欠落項目、それを要求するルール、およびそれが重要である理由を特定する 1 つの統合通知を発行しなければなりません。通知が発行されない場合、実質的なクロックは受領時に開始します。その後の証拠要求は、その証拠に真に依存する部分のみを一時停止し、経過時間を消去してはなりません。

一時停止は、管理された理由コードを使用すべきです：顧客証拠待ち、指名された第三者待ち、進行中の法的制約、検証済みのセキュリティ封じ込め、スケジュールされた顧客アクション。各一時停止には、開始通知、それを終了する特定の条件、最大レビュー間隔が必要です。プロバイダは、影響を受けないタスクの作業を継続すべきです。決定なしに期限切れになった一時停止は、黙って更新されるのではなく、自動的にエスカレーションされるべきです。

経過時間は、侵害封じ込め、矛盾する現在の権限、深刻な公開障害に適しています。リスクは一晩中継続するからです。公開されたサービスカレンダーは、通常の ID チェックには合理的かもしれませんが、休日とタイムゾーンを指定しなければなりません。グローバルな顧客は、未定義の現地営業日ルールに直面すべきではありません。最終報告は、総経過時間と除外時間の両方を示すべきであり、顧客とレビューアが一時停止がパフォーマンスを支配しているかどうかを確認できるようにします。

停止イベントも外部でなければなりません。「アナリストがレビューを完了」では不十分です。「3 つの独立した視点から訂正された RDAP 応答が観測され、完了通知が配信された」は測定可能です。「移転記録がコミットされ、古い権限が廃止され、取得プロバイダの制御が確認された」は測定可能です。顧客確認を求めるべきですが、顧客の沈黙によって、他の方法で検証された結果が永遠に開かれたままになるべきではありません。レジストリ事業者は、客観的検証後にクローズしつつ、簡単な再開権を保持できます。

目標は重大度と依存関係に従うべきである

すべてのリクエストに 1 つの目標を設定することは、非現実的であり弱いものです。レジストリ事業者は、遅延の結果によってサービスを分類すべきです。重大なインシデントには、不正なホルダー変更、矛盾する現在の割り当て状態、アクティブなルーティング認証の制御喪失、広範な権威ある公開障害、または有害な変更の信頼できる脅威を伴う侵害が含まれます。これらは継続的な対応と迅速な封じ込めを必要とします。

高優先度のケースには、取引に影響を与える実証された記録エラー、契約上の期限近くのブロックされたプロバイダ移転、または通常の権限は利用できないが現在の状態は安全な復旧が含まれます。標準ケースには、計画された連絡先変更、定期的なプロバイダ切り替え、緊急でない履歴訂正が含まれます。複雑な裁定には、行政的証拠だけでは解決できない矛盾する主張が含まれます。

正確な時間は、測定された試行後に採用されるべきですが、コミットメントの構成は最初に設定されるべきです。例えば、レジストリ事業者は、重大な封じ込めを数時間以内、高優先度の初期保護を 1 日以内、標準提出の十分性を 1 サービス日以内、定期的なプロバイダ移転を少数の経過日以内、およびそのクラスを超えるケースの理由のあるエスカレーションを要求する可能性があります。これらは設計例であり、現在の普遍的なベンチマークに関する主張ではありません。

目標にはテール義務を含めるべきです。ケースの 95% で期限を満たすことは、残りの 5% が最大年齢と必須レビューを受けない限り何も述べていません。番号リソース管理では、テールには最も依存度の高い顧客と最も高い害が含まれる可能性があります。レジストリ事業者は、パーセンタイル目標と、通常期間の定義された倍数後の独立レビューなどの絶対的なバックストップを組み合わせるべきです。

重大度分類自体も監査されるべきです。プロバイダは、パフォーマンスを維持するためにインシデントをダウングレードするインセンティブがあります。顧客は、緊急性を誇張するインセンティブがあるかもしれません。レジストリ事業者は、客観的なトリガーを公開し、迅速な分類チャレンジを許可し、アップグレードおよびダウングレードされたケースの両方をサンプリングすべきです。問題は、誰の説明がより劇的に聞こえるかではありません。どの権限表面がリスクにさらされているか、依拠がどれだけ早く害を引き起こす可能性があるか、安全な封じ込め手段が存在するかです。

測定はテールを見えるようにしなければならない

平均は、特に長いテールを持つサービスに対して誤解を招きます。9 件の移転が 1 日で完了し、1 件が 91 日遅延すると、平均は 10 日になります。その数値は誰の経験も説明しておらず、退出が失敗したケースを隠します。中央値は有用ですが、同じ理由で不十分です。レジストリ事業者は、分布と経過在庫を報告すべきです。

すべてのカスタマージャーニーについて、報告には総ケース数、完了ケース数、目標内ケース数、中央値、75 パーセンタイル、90 パーセンタイル、95 パーセンタイル、99 パーセンタイル（ボリュームが許せば）、最大年齢、未解決年齢層、再開ケースを含めるべきです。小サンプルは、不安定なパーセンテージではなくカウントとして示されるべきです。機関は、顧客時間、プロバイダ時間、バリデータ時間、第三者時間、法的制約時間を区別し、総期間を隠さないようにすべきです。

コホートは重要です。見出しの指標は、小規模ホルダー、あまり一般的でない言語を使用する顧客、レガシーリソースホルダー、プロバイダのホームタイムゾーン外の顧客、プロバイダを変更する組織に対する遅いサービスを隠すことができます。レジストリ事業者は、プロバイダ、顧客運用地域、リクエストクラス、サービスモデルごとに結果を調査し、個人および商業的に敏感な情報を保護すべきです。持続的な格差は、総合的なパフォーマンスが健全に見えても、サービスの事実です。

正確性の測定には分母が必要です。レジストリ事業者は、アクティブな記録あたりの検出された矛盾、顧客報告エラー、プロバイダ検出エラー、封じ込めまでの時間、検証済み訂正までの時間、訂正後の再発を報告すべきです。報告数の増加は、品質の低下または検出の改善を意味する可能性があります。周囲の分母と情報源がそれらを区別します。苦情を抑制して率を改善することは、開示するよりも悪いでしょう。

証拠は独立して再現可能であるべきです。イベントタイムスタンプは、署名または証人されたログから来るべきです。公的依拠表面は、独立したネットワークから観測できます。顧客通知は、その内容を公開せずに暗号化レシートを運ぶことができます。レビューアは、公開された集計を保護されたサンプルと照合できるべきです。報告への信頼は、遅延が測定されている同じプロバイダへの信頼を必要とすべきではありません。

1 つの約束がサービスチェーン全体を拘束しなければならない

顧客結果のコミットメントは、各プロバイダがローカル目標を達成してもエンドツーエンドのジャーニーが失敗する場合に失敗します。レジストラはリクエストを時間通りに転送したと言えます。バリデータは受領後迅速にコミットしたと言えます。RDAP パブリッシャーはサービスが利用可能だったと言えます。RPKI 事業者は許可されたハンドオフを受け取ったことがないと言えます。すべてのローカルダッシュボードは緑ですが、ホルダーは機関の間で立ち往生したままです。

レジストリ事業者は、各ケースに 1 つの説明責任のあるサービスオーナーを割り当てるべきです。そのオーナーはホルダーと通信し、エンドツーエンドのクロックを観察し、貢献者を調整します。これにより、オーナーがすべての外部イベントに対して法的に責任を負うわけではありませんが、責任がスカベンジャーハントになるのを防ぎます。資格のあるプロバイダ間の契約は、顧客向けコミットメントの背後に遅延費用と証拠義務を割り当てるべきです。

各ハンドオフには、受領と最大受理時間が必要です。受信サービスは、不良な素材を消滅させるのではなく、理由を付けて迅速に拒否すべきです。共有イベント識別子は、機密証拠を公開せずに、移転、記録公開、証明書移行を接続すべきです。依存関係が目標を逃した場合、ケースオーナーはホルダーに情報を提供し続け、エスカレーションを呼び出すべきです。「送信済み」としてケースをクローズすべきではありません。

プロバイダの資格には、エンドツーエンドのパフォーマンスを含めるべきです。サポートは優れているがバリデータの拒否が繰り返されるレジストラは、より良い証拠管理を必要とするかもしれません。可用性は高いが頻繁に古い状態になるパブリッシャーは、一貫性の修復を必要とします。ローカルタイミングを満たしながら証明書ギャップを作成するバリデータは、より大きなサービスに失敗しています。レジストリ事業者は、サービスチェーン属性を使用して、顧客への単一の約束を維持しながら、正しいコンポーネントを改善できます。

このアーキテクチャはまた、競争を可能にします。顧客は、一部の共通サービスが共有されていても、エンドツーエンドの結果でレジストラを比較できます。プロバイダは、不正確な属性を証拠で挑戦できます。共通バリデータは、その中心的な位置を使用して自身の貢献を消去することはできません。共有層は、責任を読み取り可能にし、誰も答えられないという意味での集団的にはしないべきです。

救済手段は測定を説明責任に変換する

結果のない目標は注意を改善するかもしれませんが、権力のバランスを再調整しません。顧客は、プロバイダが料金と管理を保持している間、依然として遅延のコストを負担します。レジストリ事業者は、段階的な救済手段をコミットメントの未達に結び付けるべきです。

最初の救済手段は、自動サービス料金クレジットです。顧客が金銭的損失を証明したり、請求を提出するためにより多くの時間を費やすことを要求すべきではありません。標準的な移転がプロバイダ管理の期限を超えた場合、関連料金の定義された部分がクレジットされます。訂正が封じ込め目標を逃した場合、クレジットは重大度と期間に応じて増加します。自動クレジットは、測定を金銭的に現実的にしつつ、低価値の請求を比例的に保ちます。

2 番目の救済手段は、ミスによって作成された直接的な訂正費用の払い戻しです：回避可能な移転遅延中の重複プロバイダ料金、レジストリサービス事業者作成のエラー後の合理的な検証費用、または意図されたルーティングセキュリティ状態を復元するために必要な緊急技術支援。証拠と上限は、この経路を管理可能に保つことができます。これは、証明可能な損失に対するより広範な補償とは異なり、因果関係のレビューと専用基金を必要とします。

3 番目の救済手段は制度的です。繰り返される未達は、強化された監視、是正計画、新規顧客受け入れの制限、追加の継続性セキュリティ、または資格喪失をトリガーすべきです。プロバイダは、クレジットを体系的に低いサービスの価格として扱うべきではありません。パターンが重要です：多くの小さなミスは弱いサービスを明らかにする可能性があり、1 つの深刻な不正な変更はパーセンテージが隠す制御の失敗を明らかにする可能性があります。

救済手段は、顧客の実質的な権利を保持すべきです。小さな自動クレジットは、より大きな請求を黙って放棄すべきではありません。緊急訂正を受け入れることは、エラーが発生した理由のレビューを放棄すべきではありません。逆に、すべての遅延が無制限の責任を生み出すべきではありません。レジストリ事業者は、自動サービス救済、直接費用払い戻し、裁定補償を区別し、各経路を依存が始まる前に明確にすることができます。

公開は、顧客を公開せずにサービスの真実を明らかにしなければならない

透明性は、身元証明、争いのある企業文書、セキュリティ詳細の公開を必要としません。レジストリ事業者は、保護されたケースレビューでパフォーマンスを開示できます。公開報告は、サービスカタログ、目標、定義、プロバイダ結果、共通サービス結果、除外、重大インシデント、経過ケース、救済総計、分類慣行の変更を示すべきです。

プロバイダレベルの報告は必要です。多くのレジストラにわたる集計は、弱いプロバイダが強いピアの後ろに隠れることを許します。共通サービスの報告も同様に必要です。なぜなら、すべてのレジストラが同じバリデータまたはパブリッシャーに苦しむ可能性があるからです。報告は、小サンプルを慎重に特定し、真の再識別リスクを生み出すものだけを抑制すべきです。抑制ルールは、結果が知られる前に固定されるべきです。

重大インシデントは、封じ込め後にナラティブアカウントを必要とします。アカウントは、顧客に見える失敗、影響を受けた権限表面、期間、検出経路、封じ込め、復旧、予防措置を説明すべきです。顧客を危険にさらす悪用の詳細を開示すべきではありません。中心的な質問は、機関が、緑のローカル測定値が失敗した顧客結果とどのように共存したかを理解しているかどうかです。

レジストリ事業者は改訂を公開すべきです。報告が後に誤っていることが証明された場合、元の数値と訂正された数値、理由、日付は見えるままであるべきです。パフォーマンスデータは、黙って改善できる広報製品になるべきではありません。サービスレベルの信頼性は、機関が自らの訂正の説明を訂正する意思に部分的に依存します。

独立したレビューアは、成功、未達、除外されたケースのサンプルをテストすべきです。失敗のみをサンプリングすると、偽の成功を見逃す可能性があります。ランダムなケースのみをサンプリングすると、深刻なテールを見逃す可能性があります。レビューアは、選択された各ケースを受領から権威ある観察および救済まで追跡すべきです。調査結果は、顧客を同意なしの例に変えることなく、管理上の弱点を特定すべきです。

サービスレベルには、それ自体の変更管理が必要である

機関は、公然と廃止せずにコミットメントを弱体化させることができます。完了を再定義し、除外を拡大し、ケースを新しいクラスに移動し、サービスカレンダーを変更し、パーセンタイルの公開を停止することができます。レジストリ事業者は、定義を顧客契約の一部として扱うべきであり、編集可能なダッシュボード設定としてではありません。

重要な変更は、通知、変更箇所、述べられた証拠、独立した影響分析を受けるべきです。変更記録は、誰が利益を得るか、どの既存ケースが影響を受けるか、サービスの改善なしに新しい定義の下でパフォーマンスがより良く見えるかどうかを示すべきです。歴史的な報告は比較可能であるか、定義間の橋渡しを提供すべきです。

緊急変更は、大規模なセキュリティイベント中に必要になる場合があります。それらは狭く、時間制限付きであり、イベント後にレビューされるべきです。緊急事態は、訂正または移転権の恒久的な停止になるべきではありません。目標を安全に満たせない場合、レジストリ事業者は改訂された顧客保護、理由、緊急例外の経路を述べるべきです。

顧客とプロバイダは、逆説的な行動を生み出す定義に異議を唱える資格を持つべきです。早期クロージャーを促進し、困難な訂正を妨げ、プロバイダに小規模顧客を避けさせる目標は、コンプライアンスが高くても不良設計です。ガバナンスは、メトリクス自体だけでなく、メトリクスをめぐる行動も調査すべきです。

5 つのケースは、結果が何を変えるかを示す

合併更新受理後の古い RDAP 名。レジストラは月曜日に証拠を受け入れ、ケースを完了としてマークします。プライベートアカウントはすぐに変更されますが、権威ある RDAP は金曜日まで古い会社を表示し続けます。活動ベースの測定の下では、レジストラは目標を達成しました。レジストリ記録正確性コミットメントの下では、公的依拠表面が受け入れられた状態を示し、ホルダーが確認を受けるまでクロックは続きます。公開障害は責任あるサービスに帰属され、期限を逃した場合は自動クレジットが続きます。

古い割り当て文書によって裏付けられた訂正申し立て。ネットワーク事業者は、公的記録が何年も前に解散した会社を特定していることを発見します。事業者は後任文書を提供します。レジストリ事業者は異なる歴史的証拠を保持しています。最終的な回答は即座にはできません。訂正コミットメントは、迅速な保存、地位チェック、依拠リスクが信頼できる場合は中立的なステータス、1 つの統合証拠要求、最大年齢までの理由のある決定を依然として要求します。不確実性は、沈黙の言い訳ではなく管理された状態になります。

無関係な債務によって妨害されたプロバイダ切り替え。現在のホルダーが取得レジストラに指示します。喪失プロバイダは、ホルダーが登録サービスとは無関係なコンサルティング請求書を争っているため異議を唱えます。曖昧な移転約束の下では、異議は無期限にケースを停止する可能性があります。レジストリ事業者のルールの下では、バリデータは許可されたカテゴリ外の異議を却下し、プロバイダ変更をコミットし、以前の権限を廃止し、商業紛争を適切なフォーラムに委ねます。退出はすべての私的請求の担保になることはできません。

アクティブな ROA を伴うホスト型 RPKI 移行。ホルダーが複数のルート認証が使用中にプロバイダを変更します。新しい権限が機能する前に登録変更を完了として扱うと、無効な状態を作成する可能性があります。古い資格情報をアクティブのままにしておくと、セキュリティリスクが生じる可能性があります。ハンドオフコミットメントは、意図された認証を棚卸し、新しい関係を確立し、依拠当事者の状態を検証し、短い重複中の変更を制限し、古い権限を廃止します。完了は、継続的な許可された効果と顧客管理を意味し、ファイルが送信されたというメールではありません。

アカウント侵害中のレジストラ障害。ホルダーが不審な変更を報告しますが、通常のプロバイダに連絡が取れません。ポータル可用性目標は保護を提供しません。レジストリ復旧コミットメントにより、ホルダーは独立した緊急チャネルを呼び出し、さらなる高リスク変更を凍結し、安全な RPKI 状態を保存し、事前に確立された証拠を通じて代表者を確認し、後継プロバイダをアクティブ化できます。顧客結果は、復旧された管理権限であり、後にすべてのインシデント期間の変更がレビューされます。

これらのケースはまた、なぜ単一の速度数値だけでは不十分かを示しています。一部の結果は公開を必要とし、一部は不確実性の合理的な処理、一部は 1 つの順序付けられたコミット、一部は暗号化継続性、一部は代替サービスを必要とします。共通の原則は、クロックが顧客と独立したレビューアが検証できる状態で終了することです。

最も強い反論は、約束を架空にせずに答えられる

最初の反論は、レジストリがすべての依存関係を制御できないということです。裁判所、企業登記所、制裁当局、顧客、ネットワーク事業者はすべてケースに影響を与える可能性があります。それは事実です。サービスレベルはそうでないふりをすべきではありません。外部の制約を特定し、制御可能な部分にタイムリーな行動を要求し、総時間と除外時間を開示し、エスカレーションを維持すべきです。限定された制御は、注意深い属性を正当化しますが、エンドツーエンドのコミットメントの消失を正当化しません。

2 番目の反論は、厳格な期限が安全でない承認を促進するということです。あらゆるコストで受け入れを促進する目標は無謀です。事業者のコミットメントは、安全な結果を測定し、狭い証拠の一時停止を許可すべきです。通常の期限と封じ込めおよび理由のあるエスカレーションを組み合わせるべきです。安全性への答えは、無期限のプロバイダ裁量ではなく、今完了できるものと裁定を必要とするものを認識するクロックです。

3 番目の反論は、公的パフォーマンス表がゲームを誘うということです。あらゆるメトリクスはゲームされる可能性があります。だからこそ、レジストリ事業者は、定義、テール、除外、再開、コホート、独立サンプルを公開すべきです。隠されたメトリクスはゲームに対して免疫があるわけではなく、顧客が挑戦するのが難しくなるだけです。複数の関連する測定は、操作をより高価にします。迅速なクロージャーが繰り返し再開を引き起こす場合、再開率がそれを明らかにします。

4 番目の反論はコストです。独立した観察、継続性の取り決め、顧客救済には資金が必要です。しかし、遅延はすでにコストを負っており、現在はホルダーとネットワークに転嫁されています。レジストリ事業者は、信頼できるサービスのコストを公然と価格設定し、重複料金、失敗した取引、緊急エンジニアリング、長期化した紛争と比較すべきです。訂正と復旧を外部化する安いレジストリは必ずしも効率的ではありません。

最後の反論は、顧客はルーティングだけを気にするということです。レジストリはすべてのルーティングを指示するわけではなく、正確な登録記録は到達可能性を保証できません。しかし、登録、RDAP、逆権限、RPKI はルーティングに関する証拠とセキュリティに影響を与えます。レジストリ事業者は、その制御外の約束をすべきではありません。それが制御する権限表面と、それが提供することを選択するハンドオフについて強い約束をすべきです。

実用的なレジストリ事業者サービス憲章

レジストリ事業者は、野心を維持する順序で設計を採用できます。まず、5 つのカスタマージャーニーとその観測可能な最終状態を定義します。すべての貢献サービスをマッピングし、完了を証明する証拠を特定します。まだペナルティを付けずに歴史的なケースを使用して一時的なベースラインを公開し、定義を現実に対してテストできるようにします。

第二に、重大度クラス、受領ルール、許容される一時停止、独立した観察を設定します。プロバイダに統合十分性通知を発行し、総時間を保存することを要求します。通常の更新、レガシー証拠、プロバイダ退出、アクティブな ROA、プロバイダ可用性の喪失を含むケースに対して測定をテストします。顧客がサービスを使用できないまま満たすことができるルールは修正します。

第三に、自動クレジットと直接費用払い戻しを追加します。プロバイダレベルおよび共通サービスの結果を公開します。独立したレビューアに保護されたサンプルへのアクセスと訂正された報告を要求する権限を与えます。繰り返される失敗を資格に結び付け、プロバイダが小さなクレジットを通じて恒久的な不履行を購入することを許可しません。

第四に、サービスカタログをより広範な救済システムに接続します。クロックの未達は、証明可能な損失が存在する場合の補償の証拠を生み出すべきですが、請求者は基本的なタイムスタンプやコミットメントが逃されたかどうかを再訴訟する必要はありません。共有事実は、因果関係と金額の別個のレビューを保持しながら、紛争コストを削減します。

最後に、コミットメントを耐久性のあるものにします。定義、歴史的系列、変更記録は公開されたままにすべきです。継続性演習は、技術と顧客アクセスの両方をテストすべきです。顧客は、サービス履歴と現在の権限証拠をエクスポートできるべきです。後継プロバイダは、事前定義された条件が満たされた場合、障害のある現職者の協力なしでサービスを引き継ぐことができるべきです。

統治テストは簡単です：スタッフが自分の画面を見るのをやめてホルダーの立場に立った場合、約束された状態が存在することを証明できますか？できない場合、そのメトリクスは診断的であり、契約的ではありません。診断はサービスの実行に役立ちます。顧客結果のコミットメントは、サービスを説明責任のあるものにします。

サービス品質は権限の一部である

インターネット番号管理は、歴史、認識、コミュニティ参加、技術的能力から正当性がもたらされるかのように議論されることがよくあります。それぞれが重要です。機関が顧客が他の場所で容易に得られない変更を管理する場合、どれも十分ではありません。権限は、エラーを訂正し、退出を許可し、制御を回復し、依存するセキュリティ状態を安全にするのにかかる時間にも表れます。

ホルダーに即時の結果を課すことができるが、自らの訂正には願望的なタイミングしか提供しないプロバイダは、非対称な力を持っています。相談を数えるが、未解決の間違った状態の日数を数えない機関は、救済なしに声を測定します。すべてのプロバイダ変更を直列化するが、エンドツーエンドのコミットメントを受け入れない共通バリデータは、調整層で独占を再現します。

レジストリ事業者は、異なる基準を選択できます。技術的測定を使用して信頼性を維持しながら、信頼性が顧客にとって意味を持つポイントでサービスを判断できます。真の外部制約とプロバイダ遅延を分離できます。安全な複雑さを見えるようにしながら、複雑さが無制限の延長になることを許可しません。逃した約束を金銭、レビュー、資格に結び付けることができます。

結果は、すべての紛争が迅速に終了したり、すべてのネットワークが到達可能であり続けるという保証ではありません。それは、観測可能な開始、正直な分類、制限された一時停止、検証可能な結果、透明なテール、失敗に対する結果という、制度的行为の保証です。これは、記録とセキュリティハンドオフが実際の運用依存関係を形成できるシステムに対する適切な野心です。

ソース

NRS および BTW の役割に関するソース