主要領域
インターネット運営・政策とルーティング
主要領域 の観点では、「インターネット運営・政策とルーティング」の調査・分析は、記事を主要な領域ごとに整理し、インターネット基盤、運営・政策、接続市場、デジタル資本といった関心分野を追いやすくします。このページでは、関連記事、公開証拠、機関、企業、人物、地域的な影響、運用上の依存関係、市場の文脈をまとめ、別々のカテゴリページに散らばりがちな情報を一覧で確認できます。また、対象領域の説明、関与しうる主体の類型、市場・制度の文脈、シグナルを比較する際に参照すべき資料も示します。運用者、アナリスト、制度・政策の関係者は、同じ領域がイベント、プロフィール、市場の変化、公開証拠、地域依存、長期的なインフラ判断に、時間を追ってどのように現れるかを確認できます。
ICANN
.Brand文字列変更は語を追加できるが、競合を新設・拡大できない
ICANN の2026年ラウンドは、競合状態にある適格な.Brand 申請者に限定的な文字列変更手段を設ける。申請名を自由に変える制度ではない。
ICANN
申請の公開部分に重大な変更がある場合、30日間のコメント期間が設けられるが、自動承認ではない
ICANN が申請の公開部分に重大な変更があると判断した場合、30日間のコメント期間が設けられる。これは変更の承認を意味しない。
番号資源社会
RPKIキャッシュのシリアル番号は鮮度のタイムスタンプではない
二つの RPKI キャッシュがそれぞれ正確なシリアル番号を返していても、どちらがより新しい世界的データを持つかは分からない。RFC 8210がシリアル番号に与える範囲は、一つのキャッシュセッションとプロトコル版である。大きい番号を新しい状態とみなすと、プロトコルには存在しない時系列を作ってしまう。
ICANN
GACコンセンサス助言が始めるのは21日間の回答記録であり、理事会の自動的な結論ではない
正式な GAC コンセンサス助言は申請者の手続上の位置を変えるが、それ自体が ICANN 理事会の決定になるわけではない。
ICANN
GACメンバーの早期警告は拒否権ではない：申請者が残すべき対応記録
2026ラウンドでは、政府代表者が申請への懸念を示す仕組みがある。しかし、その通知自体が申請の自動的な結論になるわけではない。
ICANN
単数・複数リスクは自動的に発動しない：ICANNの30日通知記録
2026年ラウンドでは、文法上の組み合わせがプログラム上の判断になるには、期限内の通知と検証可能な辞書資料が必要である。
ICANN
ICANNの異議申立てに対する上訴は再審ではない：「明白な誤り」基準で変えられること
2026年ラウンドの上訴手続は、特定された異議申立て判断の誤りを審査するものであり、争い全体を最初からやり直すものではない。
ICANN
コミュニティ異議は CPE ではない：ICANN の二つの手続が問う別々の主張
どちらの名称にも「コミュニティ」が入るが、当事者、立証要件、判断対象は異なる。
ICANN
コミュニティ優先評価に向けて申請者はどのような証拠記録を整えるべきか
基準と結び付いた記録は、支持書の量よりも有用である。
ケースファイル
被告は60のドメイン名、それでも請求を定めるのは法律だった：Harrods v. Sixty Internet Domain Names
訴訟の表題には、人ではなく60のドメイン名が被告として並んだ。この形式だけを見ると、裁判所がネットワーク上の識別子を直接処分する事件のように映る。しかし第四巡回区連邦控訴裁判所が示した答えは、もっと限定的だった。ドメイン名を対物訴訟の対象にすることはできる。だが、その手続は商標権、管轄要件、悪意、救済範囲を自動的に立証するものではない。
ICANN
ICANNは全申請文字列の地理的意味を確認する――支持書簡は何を証明すべきか
ICANN の2026年ラウンドでは全申請文字列が地理的名称の確認対象となる。必要なのは書簡の有無だけでなく、権限、真正性、適用範囲を示す証拠である。
IETF
Corey Bonnellと、署名できてもCRL署名を許されていなかった鍵
検証画面に「signature valid」と出ても、CRL を信頼する判断は終わらない。署名した鍵が正しい主体に結び付いていることと、その鍵が失効情報を署名してよいことは別だからだ。RFC 10007は、v3 証明書で欠けていた後者の確認を明文化した。
IETF
Kireeti Kompellaと、serviceを証明しなかったEcho Reply
MPLS Echo Reply が示せるのは、明示した FEC に対して作った一つの probe が、その FEC を説明できる router へ届いたという事実である。全 ECMP path、待機中の backup、同一の復路、customer payload、application 完了まで一緒に証明するわけではない。LSP Ping の価値は緑の結果より、問いの境界を残すところにある。
IETF
Eliot Learと、機器の証明ではなかった通信ポリシー
用途の限られた機器は、正常に動くために必要な通信をネットワークへ伝えられる。しかし、その申告だけでは、接続してきた個体の身元も、内部の健全性も、申告どおりに振る舞う将来も証明できない。RFC 8520の Manufacturer Usage Description は、この小さな申告を利用可能にしつつ、受入れ、絞り込み、実装、取消しの判断を local network に残した。URL、署名付き file、local policy、enforcement、観測 traffic を別々の証拠として扱うことが、この仕組みを attestation…
IETF
Tero Kivinenと、稼働中のChild SAを引き継ぐ新しいIKE SA
IKEv2 の「rekey 完了」という表示は、どの鍵が変わったかをまだ語っていない。制御を守る IKE SA だけが新しくなり、ESP や AH のパケットを運ぶ Child SA は従来の SPI と鍵のまま、新しい親へ引き継がれることがある。RFC 7296が示すのは単純な鍵交換ではなく、制御の継承、Child の保管、実際の通信を別々に証明する必要性である。
IETF
Roy Fieldingと、意図を名づけても許可は与えないHTTPメソッド
HTTP 要求の先頭にある method token は、アプリケーションの内部を知らないキャッシュやプロキシにも目的を伝える。その可視性は相互運用の資産である。しかし、語が共有されていることと、送信者に実行権限があることは別だ。Roy T. Fielding の設計思想を読む鍵は、統一インターフェースが示すものと、あえて示さないものを分けることにある。
IETF
Mark Nottinghamと、すべての利用者を代弁できないuser agent
ブラウザーはサービスを囲い、端末への権限を狭め、限られた設定を運び、別の実装へ移る余地をつくる。その働きは利用者にとって重要だ。しかし、HTTP で「user agent」と呼ばれることと、人間から委任を受けた代表者であることは同じではない。RFC 8890が残したのは、利用者優先という原則と、誰も自動的には利用者を代表しないという二重の戒めである。