メインコンテンツへスキップ

ガバナンス / IETF

IETF

IETF は、あらゆるネットワークが動かすプロトコルを書いています。ドラフト、ワーキンググループの議論、公開された標準を追い、本番環境に届く前に運用者への影響を解説します。

グローバルプロトコルガバナンス相互運用性リスク
IETF のシグナル画像
ガバナンス / IETFIETF

最新の報道

IETFの最新情報

1,656件の記事

IETFの締切が延びても、引き受ける仕事は軽くならない

IETF

IETFの締切が延びても、引き受ける仕事は軽くならない

受諾期限を10月23日へ延ばした NomCom。ART と WIT では現職も続投を希望するなか、委員会はさらに選択肢を求めている。

2026年10月17日
モデル検証は通過。それでもRFC 10057は最終承認待ちだった

IETF

モデル検証は通過。それでもRFC 10057は最終承認待ちだった

Datatracker では第44版の YANG 検証がエラー・警告ともゼロだった。一方、10月16日時点の RFC Editor キューでは RFC-to-be 10057が最終審査中で、著者承認欄は2件が未承認、所属するクラスターにも追加の保留があり得る状態だった。

2026年10月16日
RFC 10065が標準化するのはグループIDで、その意味までは決めない

IETF

RFC 10065が標準化するのはグループIDで、その意味までは決めない

RADIUS の属性で運べるグループ ID が、アクセス制御の判断と同じものになるわけではない。定義と通信フローへの対応づけは運用側に残る。

2026年10月16日
IESGがPROCON新憲章を承認、提出目標は11月と12月に

IETF

IESGがPROCON新憲章を承認、提出目標は11月と12月に

IESG は9月に審査へ回された PROCON の改定憲章を承認した。RFC2026bis と RFC2418bis は11月、IETF 議長の権限に関する BCP は12月が提出目標となる。これは作業の割り当てであり、現行ルールの変更ではない。

2026年10月16日
Mark TownsleyとRFC 6333の謝辞が示すDS-Liteの設計

IETF

Mark TownsleyとRFC 6333の謝辞が示すDS-Liteの設計

RFC 6333の謝辞は、Mark Townsley の貢献を具体的に記している。全体アーキテクチャへの入力が、検討を SNAT の方向へ導いたという。文書の著者欄には別の四人が並ぶ。この二つの記録を草案の経緯や運用上の役割と照らすと、技術的な提案が設計を動かしても、標準の執筆・承認や実サービスの運用責任まで一人に集約されるわけではないと分かる。

2026年10月16日
Tomek Mrugalski と、IPv4トンネルの行き先を示す DHCPv6 名称

IETF

Tomek Mrugalski と、IPv4トンネルの行き先を示す DHCPv6 名称

DHCPv6 の Reply は、Dual-Stack Lite の接続先となる AFTR の完全修飾ドメイン名を返せる。B4 はその名前を解決し、IPv6 網を通じて IPv4 を運ぶトンネルを試みる。しかし、名前を受け取った事実は、DNS 応答、トンネル、アドレス変換、戻りのパケット、アプリケーションの成功を証明しない。端末側の指示が小さいのは、接続先の配置、容量、可用性という仕事を事業者側へ移す設計だからだ。

2026年10月16日
UDPのECNはソケットAPIに左右される

IETF

UDPのECNはソケットAPIに左右される

同じ ECN を使うために、すべての OS が同じソケット API を持つ必要はあるのか。RFC 10055の答えは API の統一ではなく、各 OS の局所的な手段を記録し、正しい ECN 情報をアプリケーションへ届ける境界を試験可能にすることだ。

2026年10月15日
接続を覚えているのは誰か――Marcelo Bagnuloとネットワーク状態の置き場

IETF

接続を覚えているのは誰か――Marcelo Bagnuloとネットワーク状態の置き場

問い合わせには「接続がタイムアウトした」としか残らないことがある。しかし、次の動作に必要な情報を持っていた機器はどれだろう。主張が切り替わった二台のホストなのか、IPv6 と IPv4 をつなぐ変換装置なのか、それとも送信速度を調整した受信端末なのか。Marcelo Bagnulo が共著者として参加した複数の研究は、接続の継続性を支える状態が置かれる場所を変えて考える手がかりになる。

2026年10月14日
MASQUEの憲章案は終了前の作業を絞る Ethernet草案はIESGの後続審査中

IETF

MASQUEの憲章案は終了前の作業を絞る Ethernet草案はIESGの後続審査中

MASQUE の作業部会が閉鎖前に終える項目は、憲章案の改訂で減った。一方、一覧から外れた Ethernet 草案は、IESG の出版審査で別の手続きを続けている。

2026年10月14日
IETFの新規参加者向け講座は受講者を追跡しない。それでも成果の記録は要る

IETF

IETFの新規参加者向け講座は受講者を追跡しない。それでも成果の記録は要る

IETF は、習得に何年もかかることのある技術プロセスへ新しい参加者を迎えるため、自分のペースで学べる講座を調達している。受講者を評価せず、個人単位で追跡しないという方針は、プライバシーを守る明確な境界になる。では、学習を監視に変えずに、講座が役立っていることをどう示せるのか。そこにガバナンス上の課題が残る。

2026年10月9日
IETFのInternetエリアディレクター選考、二つの期限で並行

IETF

IETFのInternetエリアディレクター選考、二つの期限で並行

IETF では、Internet(INT)エリアディレクターの選考が二つ同時に進んでいる。Tommy Jensen 氏の任期途中の辞任を受けた補充と、Éric Vyncke 氏が続投を希望していない通常の2年任期の選考だ。締切も任期の終わりも異なる。

2026年10月9日
IETF個人草案、NomComの保証枠を最大5席へ 小規模プールが生む誘因も明記

IETF

IETF個人草案、NomComの保証枠を最大5席へ 小規模プールが生む誘因も明記

10月7日の改訂版-06は、自己申告で参加する opt-in プールへの保証を最大3席から5席に引き上げた。公開検証を可能にする一方、申告を検証しない設計、小規模プールで強まる選出誘因、長期に残る公開情報という三つの統治上の論点が交差する。

2026年10月9日
RFC 10065が運ぶのはグループID。ポリシー実行の証拠ではない

IETF

RFC 10065が運ぶのはグループID。ポリシー実行の証拠ではない

グループ ID を RADIUS で運べても、その文字列がどのパケット属性やポリシーに結び付くかは自動では決まらない。RFC 10065はこの対応付けを環境ごとの設定に残している。運用の焦点は、ID そのものよりも、対応表の更新と適用を追跡できるかにある。

2026年10月8日
Syslogは時計品質を報告できるが、その限界は運用者が設定する:RFC 5424

IETF

Syslogは時計品質を報告できるが、その限界は運用者が設定する:RFC 5424

複数の機器のログを一つの時系列に並べると、順序が確定したように見える。RFC 5424は、送信元が自分の時計について何を把握しているかをメッセージに添える方法を定めた。ただし、その情報を作るのも送信元であり、受信側が時計を独立に測定した結果ではない。

2026年10月8日
EAP-FASTトンネル内では、Type 6の意味が変わった:RFC 5421

IETF

EAP-FASTトンネル内では、Type 6の意味が変わった:RFC 5421

RFC 5421は、既存の EAP メソッドコードを新しい枠に持ち込んだ。Type 6は登録簿上では Generic Token Card のままだが、EAP-FAST トンネル内では異なる形式の内部交換を選ぶ。仕様は内外の使い分けを明確に禁じ分け、IESG Note はコード再利用がメソッド交渉と実装に与える互換性上の難しさを指摘した。

2026年10月8日
プロビジョニング成功だけではネットワークアクセスは決まらない:RFC 5422

IETF

プロビジョニング成功だけではネットワークアクセスは決まらない:RFC 5422

RFC 5422は資格情報の準備完了とネットワーク利用の許可を分け、サーバー未認証モードをプロビジョニング専用として扱う。

2026年10月8日
AAAは加入者を認証した。それでもHAには鍵が必要だった:RFC 5419

IETF

AAAは加入者を認証した。それでもHAには鍵が必要だった:RFC 5419

RFC 5419は、Mobile IPv6 の一部の運用者が、既存の AAA 関係を加入者認証に使いたかった理由を記録している。焦点は認証の成否だけではない。ホーム AAA が加入者を認識しても、選ばれた Home Agent(HA)には、使える形で範囲の定まった MN–HA セキュリティアソシエーションが必要になる。

2026年10月8日
CAPWAP接続の認証は、導入先への登録を意味しない:RFC 5418

IETF

CAPWAP接続の認証は、導入先への登録を意味しない:RFC 5418

RFC 5418 は WTP–AC 間の認証、特定の導入先への登録、装置の役割、クライアントデータの経路を別々に扱う。セッションが成立しても、運用上の問いは残る。

2026年10月8日
CAPWAP の発見が始まる前、DHCP は WTP の接続先候補を並べていた:RFC 5417

IETF

CAPWAP の発見が始まる前、DHCP は WTP の接続先候補を並べていた:RFC 5417

DHCPv4 または DHCPv6 のオプションは、無線終端点が起動時に試すアクセスコントローラーの順番を与える。RFC 5417 が定めるのは設定された優先順位であり、実際に制御セッションを結ぶ相手の発見と認証は後段に残されている。

2026年10月8日
RFC 5416:802.11バインディングには時代の境界がある

IETF

RFC 5416:802.11バインディングには時代の境界がある

RFC 5416は、現代の Wi-Fi 機能をすべて保証する文書ではない。CAPWAP と IEEE 802.11-2007の基線を結び、アクセスポイントとコントローラーが局、無線、QoS、BSSID、WLAN の情報を交換する方法を定める。経営上の論点は、バインディングのメッセージが能力、適用済みポリシー、利用者の継続性のどこまでを示すかである。

2026年10月8日

会員ロック解除

会員限定プロフィール分析

完全なプロフィール解説と詳細セクションを閲覧するには、ログインが必要です。

Leadership Alliance 会員限定

Leadership Alliance 解説

IP 資産の所有者と経営チームのために:アライアンス向け解説、非公開レポート、アナリストの直接サポート。

Leadership Alliance に参加