トピック
ソフトウェアライフサイクルとベンダーロックイン
「トピックの観点から見たソフトウェアライフサイクルとベンダーロックイントピックは、特定のテーマ、シグナル、または監視すべき話題を共有する記事を結びつけます。このページは、関連報道、公開情報源、市場関係者、インフラへの影響をたどる豊かな道筋を提供し、企業動向、政策決定、地域的影響、運用リスクにわたってそのトピックがなぜ重要なのかを理解するための十分な文脈を与えます。単なる記事リストにとどまらず、読者は繰り返し現れるシグナル、影響を受ける組織、公開証拠、市場背景、サービス継続性、調達、競争、コンプライアンス、戦略計画といった背景を比較できます。このページでは、トピックの対象範囲、関係するインフラ事業者や政策、報道内容を裏付ける証拠、そして通信事業者、顧客、投資家、政策関係者にとってそのテーマがなぜ重要なのかを説明します。」
インターネット史
アドレスは残った。それでもマスクは変わった：RFC 1219
RFC 1219 は、既存ホストを番号変更せずにサブネットとホスト数を増やす方法を考えた。アドレスの両端から別々に番号空間を使う発想によって、同じビット列を残せる。しかし、境界を示すマスクは更新され、経路制御は複数のマスクを扱い、二つの割当主体は最後の共有ビットを使う前に合意しなければならない。アドレスが同じでも、ネットワークの判断まで同じとは限らなかった。
インターネット史
本文は「標準」と言い、記録は「情報提供」と言った――RFC 1216
RFC 1216 は、IAB の標準化トラックに向けた新しい標準パラダイムを提案すると書いた。ところが RFC Editor の記録は Informational、Independent Stream と分類し、IETF は自らの承認を受けた文書ではなく、標準化プロセス上の正式な位置もないと明記する。本文の自己紹介と制度上の地位は、同じ証拠ではない。
ケースファイル
往復が完了しても、顧客の処理は証明されない
RFC 9516 の Echo は、設計された検査要求がサービス機能連鎖をどう通ったかを示せる。だが、その往復を顧客トラフィックの処理完了やサービス回復の受領書に変えてはならない。
インターネット史
トラップは定義済みだった。事象はまだ観測されていない――RFC 1215
障害が起きる前から、トラップには名前も変数も説明も番号もある。RFC 1215 は1991年、その定義を SNMP の Trap-PDU に結び付ける手順を整えた。ただし、定義が整ったことと、実行時に何かを観測したことは別である。認識、生成、送信、受信、確認、対応には、それぞれ別の記録が要る。
ケースファイル
ACK は次の送信を許した。経路はまだ回復していなかった：RFC 9937
ACK が戻り、送信側がもう一度送れるようになった。その事実と、共有経路やサービスが回復したという判断は別の記録である。
インターネット史
アドレスは不達になった。主リストに載っていたとは限らない――RFC 1211
不達通知に一つの宛先が現れたのに、主リストを検索しても見つからない。RFC 1211 が描いたのは、記録漏れではなく入れ子になった配布構造だった。主リストが保持するのは一個の展開用別名だけで、その先の会員表は別組織が管理している。中央の担当者には手掛かりはあっても、最後の一行を書き換える権限はなかった。
ケースファイル
内容種別は YAML だった。決定はなおローカルに残った。
`application/yaml` は到着した表現の形式を知らせる。受信者がそれを受け入れ、解釈し、現実の状態を変えてよいことまでは知らせない。
ケースファイル
コントローラには枠組みがあった。決定的サービスはまだ成立していなかった：RFC 9938
RFC 9938 は DetNet コントローラプレーンに必要になり得る仕事を整理する文書である。フロー要求、経路計算、設定投入を、実際に成立し維持され観測されたサービスの証明へ変えるものではない。
ケースファイル
委任された LSP は、委任されたネットワークではない
RFC 9504 は GMPLS 制御ネットワークで状態保持型 PCE を使いやすくする。だが、PCEP 上の記録を運用権限の移転に、あるいは経路要求をサービス実績に変えるものではない。
ケースファイル
アルゴリズムは公告された。それでも経路はまだ計算されていない：RFC 9502 の IP Flex-Algorithm 境界
同じ番号を配ったからといって、同じ結果が生まれるわけではない。RFC 9502 が IPv4 と IPv6 のプレフィックス到達性を IP Flexible Algorithm に結び付けられるようにしても、その番号はパケットの通過記録でも、SLA の達成印でもない。定義の合意、IP データプレーンごとの参加、局所計算、FIB への導入、実測された通信は、意図的に別の層として残る。
インターネット史
サーバーは 250 と答えた。アカウントは存在しないかもしれない――RFC 1204
同じ三桁が、同じ事実を意味するとは限らない。RFC 1204 では、構文が正しい `USER` なら、未知のユーザー名にも `250` を返すことが推奨された。アカウントの有無を外から調べさせないためである。パスワードの照合、メッセージ本文の入口、ローカルキュー、配送は、その後に残された別の境界だった。
ケースファイル
受信者の鍵は示された。それでもメッセージは開かれていない：RFC 9936
RFC 9936 は CMS に ML-KEM の受信者経路を載せる。検査できる記録は証明書または公開鍵と、その鍵向けの暗号文を示せる。しかし秘密鍵の管理、復号の成功、内容の処理、組織上の決定までは示さない。
ケースファイル
Bundle は受信された。だがそれだけでは保管責任は成立しない：RFC 9171 の保証境界
遅延耐性ネットワークでは、「受信された」という語が結論のように見えやすい。あるノードにコピーがあり、状態報告がそれを示し、ダッシュボードが緑色になる。しかし、それは誰かが継続的な保管を引き受けたこと、宛先アプリケーションがペイロードを処理したこと、ましてそのペイロードに結び付く作業が完了したことを示さない。RFC 9171 の価値は、これらを一つの成功表示に混ぜない点にある。
ケースファイル
プレフィックスは登録された。それでも経路はローカルな約束にすぎない：RFC 9926
低消費電力ネットワークで IPv6 プレフィックスが隣接ルータに登録されたことは重要である。しかしそれは、公的な帰属、経路全体の成立、パケット配達、背後のサービス成功を一度に証明するものではない。
インターネット史
標準は複合オブジェクトを知っていた。段落は profile が選んだ――RFC 1197
「変換なし」という記録ほど、文書交換では誤解を招きやすい。1998年の ODA 用 MIME 規則は、データ本体を変換しないと記した。それでも profile、document class、受信側の実装、製品内の対応表は必要だった。RFC 1197 は、その理由を8年前に一つの単語――paragraph――で示していた。
ケースファイル
グループは新しいエポックに達した。だが意思決定には達していない：RFC 9420における MLS の境界
暗号学的なグループは、きわめて正確に新しい状態へ移れる。Commit が処理され、鍵が更新され、GroupContext が変わり、新しいエポックが存在する。しかし、その技術的事実だけから、関係者が読んだ、理解した、同意した、権限を行使した、あるいは業務上の行為を完了したとは言えない。RFC 9420 の強みは、前者を確かなものにしながら、後者まで主張しない点にある。
ケースファイル
スケジュールは有効だった。変更は実行されていなかった：RFC 9922
定例保守の行に `enabled`、次回時刻、前回の発生時刻、増えたカウンタが並んでいる。その表示は時間規則については有益である。しかし、誰かが変更を許可し、呼び出し、対象で完了させ、結果を確認したという証明にはならない。
インターネット史
中継点は識別子を承認した。宛先はまだストリームを受け入れていなかった――RFC 1190
1990年の ST-II では、経路の途中から肯定的な返事が届いても、まだ送信を始めてはならなかった。隣の agent は制御メッセージを受け取り、転送用の短い識別子を使えると答え、資源を確保していたかもしれない。しかし宛先 application の参加判断は、そのさらに先に残っていた。RFC 1190 は「途中まで進んだ」と「相手が受け入れた」を wire protocol の別イベントにした。
ケースファイル
主張は選択的に開示された。それでも記録は完全ではない：RFC 9901と「ないこと」の証拠
必要な情報だけを見せることは、欠落を隠す不正ではなく、RFC 9901 が意図して支えるプライバシーの機能である。ただし、表示された主張が検証できることと、表示されなかった情報が不要だと分かることは別である。
ケースファイル
時刻印はペイロードに届いた。署名の時刻ではない：RFC 9921
保護された COSE ヘッダーに RFC 3161 のタイムスタンプトークンが入っていても、そのトークンが発行された時点で COSE 署名が存在したことにはならない。RFC 9921 は、ペイロードの存在時刻と署名の存在時刻を混同しないために二つの構成を分けている。