トピック
レジストリガバナンス
「トピックの観点から見たレジストリガバナンストピックは、特定のテーマ、シグナル、または監視すべき話題を共有する記事を結びつけます。このページは、関連報道、公開情報源、市場関係者、インフラへの影響をたどる豊かな道筋を提供し、企業動向、政策決定、地域的影響、運用リスクにわたってそのトピックがなぜ重要なのかを理解するための十分な文脈を与えます。単なる記事リストにとどまらず、読者は繰り返し現れるシグナル、影響を受ける組織、公開証拠、市場背景、サービス継続性、調達、競争、コンプライアンス、戦略計画といった背景を比較できます。このページでは、トピックの対象範囲、関係するインフラ事業者や政策、報道内容を裏付ける証拠、そして通信事業者、顧客、投資家、政策関係者にとってそのテーマがなぜ重要なのかを説明します。」
記事
ARINの受入スイッチは再割り当てを同意付きの登録関係にする
2026年1月以降、組織は上流事業者が自らの Org ID へ新しい再割り当てや再配分を結び付ける前に、その操作を拒否できる。これは公開記録への望まない関連付けを防ぐ仕組みであり、既定の受入状態が案件ごとの同意を示すわけでも、成立した記録がネットワーク運用や所有権を証明するわけでもない。
ICANN
1回のRSP評価は複数gTLDに使えるが、対象は資格が認められた特定サービスに限る
評価は gTLD をまたいで再利用できるが、ICANN の資格は特定のレジストリサービスに限られる。
記事
AFRINICのPDP継続案には権限マップが必要だ
新しい作業部会案は、会社統治が止まったときにもポリシー策定を継続させようとしている。手続の明文化には価値がある。難題は、理事会が動けないときに誰が合法的に行動できるかである。
ICANN
RSPの網羅性は事業者数ではなく機能表で確かめる
複数のレジストリサービスプロバイダーを挙げても、重要な機能が未割当のままになることがある。ICANN の2026年ラウンドでは、Main、DNS、DNSSEC、任意の Proxy という各 RSP の役割と数の上限が異なる。
ICANN
RSPの指定は契約段階の確認ではない
申請者は申請書でレジストリサービスプロバイダーを指定できる。契約手続中には、ICANN が指定されたプロバイダーへ別途確認を求める。申請者による選択、ICANN の確認要請、プロバイダーの実際の回答は同じ証拠ではない。
記事
AFRINICのコンプライアンス画面には制裁より先に不服申立ての経路が要る
AFRINIC は、会員がポリシー上の義務を把握しやすくするコンプライアンス・ダッシュボードを検討している。だが、赤い表示がサービス停止、資源の取消し、会員資格の終了につながり得るなら、可視化と執行判断を分離する設計が先に必要だ。AFRINIC 自身の影響評価も、その理由を示している。
ICANN
RSP選定は評価前まで待てるが、無期限ではない
ICANN の2026年ルールでは、レジストリサービスプロバイダーを指定せずに申請できる。ただし申請者と申請内容の評価に入る前に、最低限必要な重要レジストリ機能を担うプロバイダーを特定しなければならない。
ICANN
バリアント文字列集合は文字列ごとではなく一体で競合する
同じバリアント文字列集合の文字列を異なる申請者が求める場合、ICANN の2026年ルールは申請されたプライマリ文字列と申請された割り当て可能なバリアントを一つの競合単位として扱う。
記事
LACNICのPAIクライアントはJava 8対応を掲げるが、最新版JARはJava 17を要する
公開 README には「Java 8以上」とある。一方、JitPack から取得できる1.5.1の JAR では、十二個すべての class ファイルが major version 61、すなわち Java 17向けだ。これはサービス障害の証拠ではない。人が読む互換性の説明と、JVM が読む実行条件との間で、版の対応が切れているという証拠である。
記事
APNICのAPI障害告知はレジストリAPIを名指ししていなかった
`api.APNIC.net` と `registry-api.APNIC.net` の間には、「registry」と一つのハイフンがある。APNIC が8月5日の障害告知で示したのは前者であり、レジストリ更新用に公開している仕様が示すのは後者だ。この差だけで両サービスの独立性は証明できない。しかし、「API」という総称だけでは、障害がどの権限面に及んだのかを特定できないことは証明できる。
ケースファイル
HTTPは200、レジストリ命令は失敗
EPP over HTTPS の最新ドラフトは、運用画面の「成功」を二つに分ける。HTTP の200は Web 経路の結果であり、EPP 応答はレジストリ命令の結果である。処理後に応答だけが失われた場合、どちらの数字からも再実行の許可は生まれない。
記事
ARINのROA影響警告はWeb向けで、API向けではない
ROA を確定する直前に、その変更が観測中の経路をどう変えるか確かめられる――ARIN が開発中の機能は、判断を取り戻すためのよい仕組みだ。ただし、その仕組みは ARIN Online に置かれ、同じ発行権限を自動処理する API 利用者は、同種の情報を外部で調達する設計になっている。
記事
ARINの地球外アドレス案、初回割り当てまでに四つの関門
NRPM の条文案があっても、登録サービスが始まるわけではない。技術、資源、組織権限、RIR 間合意という別々の判断を、公開された順序で確認する必要がある。
記事
IANAレビューは関与を十分とした。AFRINICには投票権を持つコミュニティ委員がいなかった
2025年の IANA 番号サービス・レビューには、同時に成立する二つの記録がある。委員会は有効な定足数のもとで技術評価を終えた。一方、公開された構成表には AFRINIC のコミュニティ選出委員が一人も載っていない。意見募集はゼロ件で、報告書はアウトリーチと関与を十分と評価した。問題は技術結論を覆すことではない。五地域の席、投票資格、働きかけ、応答を同じ時点で確認できる参加証跡がないことである。
ICANN
既存gTLDのバリアント申請は処理上優先されるが、承認ではない
ICANN は一部の申請を処理順で先行させる。2012年ラウンドの既存 gTLD に関する割り当て可能なバリアント申請である。この優先扱いが変えるのは順序であり、実質的な結果ではない。
リーダー
Razvan C. Opreaと、運用限界に名前を与える規律
技術運用のリーダーシップは、成功した施策の一覧だけには現れない。測定が何を捉えられないのか、公開データが何を隠しているのか、外部サービスへの依存がどこで選択肢を狭めるのかを、意思決定の前に言葉にすることにも現れる。Razvan C. Oprea の公開記録は、その慎重さを、研究、メール運用、クラウド戦略、サービス重要度評価という異なる場面で示している。
記事
ARINの調和案には意味差分台帳が必要だ
ARIN-2026-4 は明確化を掲げるが、ほぼ並行する二つの条文は行為主体と法規範の強さが異なる。現行文は登録による一意性の保証を英語の動詞「guarantees」で表し、提案文は割り当て済み資源の一意性を確保する公開レジストリを英語で「necessary」と位置づける。この違いを見えなくしてはならない。
記事
ARINの財産表現提案には文書管理台帳が必要だ
政策マニュアルから一文を削除しても、権利の問題が決着するわけではない。読者が証拠をたどる経路が移動するだけだ。ARIN-2026-3 で重要なのは、その移動後も、現行の記述、根拠となる文書、版、対象となる保有者を追跡できるかである。
ICANN
既存gTLDのバリアントは一つの2026年契約に統合される
既存 gTLD の割り当て可能なバリアントを申請することは、従来の契約を変えずにラベルだけを追加することではない。ICANN の2026年規則は新しい基本レジストリ契約への移行を求め、既存 gTLD と全バリアントを一つの契約にまとめる。
ICANN
既存gTLDのIDNバリアントを申請できるのはそのレジストリ運営者だけ
ICANN の2026年ラウンドでは、既存 gTLD の IDN バリアント申請者は、その gTLD のレジストリ運営者と同一の法人でなければならない。