トピック
ソフトウェアライフサイクルとベンダーロックイン
「トピックの観点から見たソフトウェアライフサイクルとベンダーロックイントピックは、特定のテーマ、シグナル、または監視すべき話題を共有する記事を結びつけます。このページは、関連報道、公開情報源、市場関係者、インフラへの影響をたどる豊かな道筋を提供し、企業動向、政策決定、地域的影響、運用リスクにわたってそのトピックがなぜ重要なのかを理解するための十分な文脈を与えます。単なる記事リストにとどまらず、読者は繰り返し現れるシグナル、影響を受ける組織、公開証拠、市場背景、サービス継続性、調達、競争、コンプライアンス、戦略計画といった背景を比較できます。このページでは、トピックの対象範囲、関係するインフラ事業者や政策、報道内容を裏付ける証拠、そして通信事業者、顧客、投資家、政策関係者にとってそのテーマがなぜ重要なのかを説明します。」
IETF
公開 DNS が「ここから先は自分の道ではない」と言える設計
親 zone が子 zone の境界を認めながら、public に到達可能な authoritative server を装わない。空の NS target という提案の核心は、public namespace の権限と private namespace の現実を混同しない点にある。
ケースファイル
イントロスペクション応答をアクセストークンとして受け入れた瞬間、署名は境界を守れなくなる――RFC 9701
JWT は広く使われる器であり、同じ発行者、同じ署名鍵、似た `iss` と `aud` を持つことがある。だからこそ RFC 9701 の `typ` と入れ子構造は装飾ではない。何についての証明かを失えば、真正な応答が別の権限へ化ける。
IETF
SigTag が省くのは再送であって、検証ではない
resolver が signed Merkle Tree Ladder を既に持つと知らせれば、authoritative server は大きな ladder を再送せず condensed signature だけを返せる。だが、その通知は cache の存在証明ではない。signer との結び付け、検証、失敗時の full signature 回収は別の責任として残る。
ケースファイル
同じ基準エフェクトが、二台の機器で別の物理出力になる――RFC 9695
基準機器には八つのアクチュエーターがあり、受信機には二つしかない。それでも両方が同じ触覚ファイルを「正常に処理」できる。登録名は配送先を示しても、統合された効果や削られた力を語らない。RFC 9695 が開いた媒体経路で、最も重要な証拠は受理の後に生まれる。
IETF
SUITの署名では、端末が追加命令を理解できるか分からない
更新マニフェストが正しく署名されていても、配布先の機器がその中の任意拡張を実装しているとは限らない。SUIT 更新管理案の第16版は、この対応状況を把握する責任が個々の導入環境にあることを明確にした。
ケースファイル
後継鍵は30日待った。検証者群に共通の時計はなかった――RFC 9691
A 側と B 側の TAK が互いを正しく指し、署名検証も通る。それでも二つのリポジトリが一瞬だけ異なる世代を示せば、取得時刻の違う検証者は別の世界を見る。RFC 9691 の移行は、鍵だけでなく観測履歴の設計である。
ケースファイル
証明書に鍵はあった。受信者の「受け入れる」はなかった――RFC 9690
有効な RSA 証明書を見つけた送信側が、そこから RSA-KEM 対応まで読み取ってしまう。RFC 9690が止めているのは、その小さく見える飛躍だ。鍵の存在、用途の表明、受け入れ可能な部品の組み合わせ、実際の復号処理は、同じ証拠ではない。
IETF
LAKEのAuthKEM改訂案、身元を明かす4メッセージ案を削除
応答回数を減らす設計は、必ずしも同じ秘匿性を保てない。9月28日付の AuthKEM 作業部会草案では、開始側の資格情報識別子を最初から平文で送る短縮案が姿を消した。残る5メッセージ方式でも、双方の認証が終わる時点は同じではない。
ケースファイル
経路はつながった。制御の履歴は二つのままだった――RFC 9689
旧経路の予約を消す直前に、境界ルータが再起動したとする。左側は LDP または RSVP-TE、右側は PCECC の個別命令で動いている。RFC 9689のプロキシは両者を接続できるが、どこまで進んだ変更なのかを一つの履歴にしてはくれない。
IETF
サーバーはファイルをキャッシュ不可と示した。それでも従うのはクライアントだ
NFSv4.2 に、特定ファイルのデータをクライアント側へ長く保持しないよう求める標準の合図が加わろうとしている。この仕組みが有用なのは、命令と実行済みの証拠を混同しないからだ。
ケースファイル
RSA では必要な `NULL` が、ECDSA では違反になる――RFC 9688 の非対称な証拠
同じ SHA3 family を扱う二つの署名経路に、同じ正規化規則を適用してはいけない。RFC 9688 は RSA-with-SHA3 に `NULL` を要求し、ECDSA-with-SHA3 には parameters の不在を要求する。algorithm 名だけを残す inventory は、この差を最初に失う。
ケースファイル
Anycast の購読者が三つあっても、一つの packet が三か所へ届くわけではない
RFC 9685 は複数の constrained node が同じ anycast address を購読できるようにする。しかし購読数は delivery fanout ではない。RPL は一つの packet について一つの候補を選ぶため、購読、merged route、選択 policy、選ばれた path、application receipt は別々に残さなければならない。
ケースファイル
新しい nonce に答えた Quote でも、古い Reference Values なら誤判定になる
RFC 9684 は TPM Quote と測定 log を YANG RPC で取得する共通面を定義する。Freshness は replay を防ぎ、signature は選択された Evidence を保護する。しかし、対象 TPM/PCR、測定 policy、基準値、Verifier の appraisal、Relying Party の権限、実際の enforcement は別々に証明しなければならない。
ケースファイル
同じ運用者の CDN でも、別 origin なら RRDP は追ってはならない
RFC 9674 が比較するのは会社名でも証明書の説明でもない。Update Notification File の scheme、host、port と、Snapshot、Delta、redirect の行き先である。運用上は一つの配信基盤に見えても、origin が変われば RRDP の取得権限はそこで止まる。ただし同一 origin は RPKI object の妥当性や router の状態まで保証しない。
ケースファイル
一つ目の option は処理された。二つ目は、転送を守るために読み飛ばされた
RFC 9673 は、IPv6 Hop-by-Hop Options を「すべての router が同じように処理する」という前提から切り離した。複数 option の順序は単なる encoding ではない。限られた処理能力の中で、どの仕事を先に渡すかを決める operational policy である。
ケースファイル
相互接続試験は合格した。だが、どの OWE を試したのかが書かれていなかった
RFC 9672 により、OWE の今後の保守は IETF から IEEE 802.11 ワーキンググループへ移った。制度上の継承が明確でも、試験報告に規範文書の版、製品 build、設定、観測結果が結び付いていなければ、現場の適合性は特定できない。
IETF
一つのネットワーク機能、四つの安全業務：RFC 9509が運用者に残した証明書構成
5G Core の証明書は、単なる「信頼済み」の札ではない。TLS、クライアント表明、SEPP 間の JSON 保護、OAuth トークン署名では仕事が違う。RFC 9509 は不足していた三つの用途名を加えたが、鍵を一つにまとめるかどうかは決めなかった。
ケースファイル
ShareNotification は届いた。それでも新しい権限を使えた証拠にはならない
RFC 9670 は共有変更を通知できる共通モデルを JMAP に与える。しかし通知オブジェクトが存在すること、利用者が変化に気づくこと、許可された操作が実際に成功することは、別々の出来事である。
IETF
同じ1バイトでも、タイムアウトは同じではなかった：RFC 9510
CCNx の1バイト時間値は、旧式フォワーダーには255ミリ秒以下、新方式のフォワーダーには数年として読まれ得る。RFC 9510 が圧縮したのは長さだが、運用側が保存すべき証拠は増えた。
ケースファイル
verifier は通過した。hook の呼び出し回数はゼロのままだった
安全にロードできることと、意図した実行点にイベントが到達することは別の事実だ。program ID と link が存在しても、対象経路を一度も通らなければ、その policy は現実に判断していない。