プロフィール
Research
Research のプロフィールは、人物、企業、機関、その他のエンティティを横断し、BTW.MEDIA の報道の背後にある対象を比較したい読者に、まとまった情報を提供します。このページでは、公開上の役割、関連イベント、証拠一式、役職・責任の変化、事業展開の範囲、ガバナンス上のリスク、組織間の関係性、市場での重要性を比較できます。企業や人物の記録は通常のニュース時系列とは分けて管理され、見出しの背後にある主体、そのプロフィールを裏付ける証拠、そしてそのプロフィールを重要にするインフラや市場との関係を理解できます。プロフィールが誰・何を表しているか、どの公開情報源がそれを支えているか、企業・市場・ガバナンス機関・イベントとどう結びついているか、そして対象の変化に伴い今後も注目すべき点を確認できます。
IETF
一つの削除命令が他者のドメインを壊す：RFC 9874 と EPP 依存関係の制御
破壊的な EPP 状態遷移は、削除を要求したクライアントだけに閉じないことがある。従属ホストが別のクライアントのスポンサーするドメインと関連付いたままなら、その削除は DNS の依存関係、名前解決、クライアント間の整合性に波及し得る。RFC 9874 の権威は RFC Editor にあり、新しい EPP コマンドやレジストリ所有権の変更を定義するものではない。
IETF
第2のアドレスが主アドレスになる：RFC 9873 が変える EPP 連絡先データ
EPP の連絡先更新は、より明確な状態遷移を表せるようになる。連絡先オブジェクトに追加のメールアドレスを一つ保持し、任意の `primary` 属性で主として扱うアドレスを示す。ただし、プロトコルが記録するのは関係であり、メールボックスの所有、配送、下流処理全体を保証するものではない。
IETF
デフォルト拒否は欠落した EBGP ポリシーを暗黙の権限から明示的な障害へ変える
外部 BGP セッションが確立していても、経路を受信・広告する権限が未定義のことがある。RFC 8212 はこの境界の既定値を変える。インポートポリシーがなければ受信せず、エクスポートポリシーがなければ広告しない。経営上の問いはセッションが稼働しているかではなく、誰が各方向を承認し、その承認がアップグレード後も維持されるかである。
インターネット史
公開鍵を信じられるものにした連鎖――PEMの証明書管理
公開鍵を入手しただけでは、その公開鍵が指定された通信相手のものだとは判断できない。RFC 1422は、証明書、認証機関、検証経路、失効情報を組み合わせ、Privacy Enhanced Mail における鍵の帰属を検討可能な制度的手続きとして構成した。
IETF
拡張 uRPF は全経路を信頼せず、実現可能な送信元経路を許可する
マルチホーム接続の顧客から届く正当なパケットが、受信ルーターの返路とは別のリンクを通ることがある。厳格な検査はそれを誤って破棄し、緩い検査は経路がある送信元を広く許す。RFC 8704 はその中間として、インターフェースごとに実現可能な送信元集合を作り、その権限と費用を明示する。
IETF
問い合わせより先に届くプレフィックス：RFC 9872 が変える NAT64 発見
IPv6 のみのネットワークから IPv4 サービスへ到達する端末は、アドレス合成に使う IPv6 プレフィックスを知る必要がある。RFC 9872 は、その情報をアクセス網の信号として扱う。まず Router Advertisement から PREF64 を学習し、利用できない場合だけ DNS 発見を使う。
インターネット史
帯域外ではなかったポインタ：TCP緊急データ
TCP の緊急データは、小さくても長い歴史を持つ制御面である。URG フラグによって16ビットの緊急ポインタが有効になるが、RFC 793はその境界を相反する二通りで記述した。曖昧さは仕様から実装とアプリケーション API へ移った。
IETF
ZONEMDは転送完了後にセカンダリがゾーン全体を検証できるようにする
ゾーン転送が完了したという事実は、配送処理が終わったことを示すにすぎない。受信側が組み立てたゾーンが、公開側の意図した完全な内容と一致することまでは証明しない。ZONEMD はゾーン全体のダイジェストを加え、「受信」と「一致の検証」を別々の制御点にする。
IETF
ビットマップが示すのはUDPオプションの出現であり、動作ではない：RFC 9870
RFC 9870は、フロー内で観測した UDP オプションの Kind を IPFIX で簡潔に報告する仕組みを定めた。その証拠能力は意図的に狭い。記録するのは「見えた」という事実であり、パケットの順序、受信側の処理、アプリケーションの結果ではない。
IETF
ネガティブトラストアンカーはゾーンを変更せずにリゾルバーのDNSSEC検証を止める
署名済みゾーンの設定が破綻したとき、検証リゾルバーには失敗を維持する道と、対象を厳密に絞ったローカル例外を設ける道がある。ネガティブトラストアンカーはゾーンを修復せずに到達性を戻せるが、その間、特定の枝に対する DNSSEC の保証を外す権限はリゾルバー運用者に移る。
IETF
Mukul Srivastavaと、RIBを数えても経路を見なかったBMP Gauge
数値は正確でも、観測対象を越えて語ることはできない。RFC 9972 は、どの RIB のどの段階に今何本の経路があるかを BMP で示す Gauge を追加した。これは経路そのものの記録でも、ポリシーの理由書でも、転送の成功証明でもない。Mukul Srivastava が編集に加わったこの仕様の良さは、数字の有用性と限界を同時に名前で残したところにある。
IETF
BGP Role はピアリング関係を経路リークの境界に変える
一つの経路も交換しないうちに、二つのネットワークは相手をどの種類の隣接先と考えているかを示せる。RFC 9234 はその双方の申告を制御に変える。整合しない Role ならセッションを成立させず、Only to Customer 属性なら、印を付けた経路が誤った商業上の境界を越えて進むのを止められる。プロトコルが検査するのは意図の整合性であり、その背後にある契約の真偽ではない。
リーダー
Abdiel Marin――眼科診療のワークフローを支えるソフトウェア設計
Abdiel Marin が EyeMD EMR を形にした出発点は明快だった。眼科向けソフトウェアは、汎用的な電子カルテの分類に現場を合わせさせるのではなく、診療所で実際に行われる仕事に沿うべきだという考えである。専門画像、相互運用性の標準、エッジ処理、患者対応を結び付けた彼の判断は、創業者が日常の経営を離れた後に、その設計思想が保たれるかを読む手掛かりになる。
IETF
Cédric Fournetと、ログを完全にはしなかったレシート
署名付きの証明は、あるエントリーとある木の状態については精密に語れる。しかし「透明性」という語だけで、見えていない出来事や根、運用上の判断まで代弁できるわけではない。
リーダー
Aaron MoreckとNaaS・SD-WANを支えるネットワークサービスの判断
公開資料は、Aaron Moreck を IntegraONE のネットワークサービス、顧客接続、管理型ファイアウォール、SD-WAN の実務面に位置付ける。個人が全成果を支配したという証拠ではない。
IETF
CATS OAM は経路方針を検証できるが、救済策を選べない
CATS の OAM 草案は、到達可能性と利用可能性を同じものとして扱わない。ネットワーク上の宛先が応答していても、背後のアプリケーションは停止、停滞、資源枯渇していることがある。そこで草案は、リンク、パス、インスタンス、サービスという四つの観測層を置き、実際の転送が CATS Path Selector の選択と一致するかを確認する。
リーダー
Amit Thapa Chhetriとネパールのケーブルインターネットを支えた長い道のり
Subisu の創業史は、一人の英雄がすべてを実現した物語ではない。新しいサービスを制度に理解してもらい、取得までに時間を要した免許を継続的な運用能力へ変えたチームの記録である。Amit Thapa Chhetri の足跡は、個人の功績を誇張せずに、その移行を考える材料になる。
IETF
IETFの調査はガバナンス問題を診断できる。是正を承認することはできない。
IETF Community Survey 2025 が残した価値は、「コミュニティ」という大きな言葉を一つの数字にすることではない。何を母集団とし、どの回答を有効とし、どこに不確実性が残るかを示した上で、組織が見落としがちな経験を可視化した点にある。これは責任ある検討を始める根拠にはなる。しかし、誰が決めるか、何を変えるか、変化が効いたかを調査自身が決めることはない。診断と処分の間には、別の責任記録が必要である。
SANOG
SANOG 34は開催都市を変更したが、危機対応の権限系統は公開しなかった
SANOG 34は、運営上難しい変更を実行した。SANOG がスリランカの最近の治安状況と説明した事情により、地域会合をコロンボからコルカタへ移しながら、日程を維持したのである。SANOG 自身の記録は、開催地の変更、当初と変更後のホスト、そして現地ホストの助言を受けて決定したことを示している。一方、その決定を支えた完全な権限系統は公開していない。この空白が重要なのは、緊急時に継続性を確保する行為も、組織権限の行使だからである。
IETF
Thomas Graf と、制御プレーンの出所を示さなかった MPLS ラベル番号
運用画面に現れたラベル番号は、もっともらしい物語を急いで作らせる。番号を見つけ、集計し、想定していた移行と結び付ければ、原因まで分かったように見える。Thomas Graf が単著した RFC 9160 は、その一歩前で止まる。MPLS ラベルの数値だけでは、それを割り当てた制御プレーン・プロトコルを確実には特定できない。