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

ガバナンス / IETF

IETF

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

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

最新の報道

IETFの最新情報

1,656件の記事

AIエージェントは動いた。管理画面が知ったのは後だった

IETF

AIエージェントは動いた。管理画面が知ったのは後だった

設定変更を命じた直後、管理画面には「結果不明」と出る。あとで成功の証拠が届いたとき、最初の記録を成功に書き換えてしまえば経緯が消える。失敗と決めつけて再実行すれば、同じ操作が二度走りかねない。10月28日に更新された IETF の個人草案 SAMP は、遅れて判明した結果に新しい記録番号を与える。

2026年10月28日
JMAP草案はバイト列を預かる。検索窓口には中身が見えない

IETF

JMAP草案はバイト列を預かる。検索窓口には中身が見えない

「保存できた」と「探し出せる」は、同じ約束ではない。10月28日に更新された JMAP 作業部会の草案は、オブジェクトのメタデータに任意のバイト列を収める器を加えた。サーバーは器をそのまま返す。一方、文字列検索も部分更新も中へ入れない。棚に置かれた印が、索引に載った印になるわけではない。

2026年10月28日
IANAは6番を決めた。プレフィックスの勝敗はリンク上で決まる

IETF

IANAは6番を決めた。プレフィックスの勝敗はリンク上で決まる

SNAC ルーターの S フラグに、IANA の登録簿で「6」という番号が付いた。仕様対応の表には書きやすい数字だ。しかし隣のルーターが別のプレフィックスを広告しているなら、番号だけではどちらが退くか決まらない。広告を出すインターフェース、RA-Guard を通るかどうか、受信側の比較規則。この三つを確認して初めて、登録簿の一行が現場の判断になる。

2026年10月28日
AI通信を振り分けるBGPの札、その番号はまだ実験用だ

IETF

AI通信を振り分けるBGPの札、その番号はまだ実験用だ

大きな通信が同じ経路に重なれば、並行する回線が空いていても一部だけが詰まる。新しい提案は、宛先の装置が付けたグループ番号を経路に載せ、入口の装置が自分の回線群に対応づける。ところが札の先頭に描かれた `0x83` は、IANA の表では実験用の番号だ。

2026年10月28日
下請けの名前は伏せられる。引き受けた引き継ぎは消せない

IETF

下請けの名前は伏せられる。引き受けた引き継ぎは消せない

一つの仕事が複数の組織のエージェントを渡り歩く。途中の担当者が別の相手に仕事を回しても、その相手の名前を上流に全部明かす必要はない。ただし、元の指示が変わったとき、自分が管理すると引き受けたつながりまで黙って切るわけにはいかない。10月28日の IETF 個人草案は、その境目を描く。

2026年10月28日
小さくなったのはパケットだ。トンネルの道幅ではない。

IETF

小さくなったのはパケットだ。トンネルの道幅ではない。

トンネルの管理画面に「MTU 1500」と出る。受信側は確かに1500バイトのパケットを復元できる。ところが途中の経路が見るのは、圧縮後のデータグラムとその外側のヘッダーだ。よく縮む試験パケットが通ったからといって、同じ元サイズの業務パケットまで通れるとは限らない。MASQUE の改訂草案は、見栄えのよい一回の成功に隧道全体の容量を代弁させるなと、サイズの責任を三つに分けた。

2026年10月28日
経路数はまとめて報告できる。ゼロだけは順番を待たない

IETF

経路数はまとめて報告できる。ゼロだけは順番を待たない

同じ BGP 属性を持つ経路が増えるほど、監視用の通信には同じ説明が何度も乗る。10月28日の新提案は属性の組を先に登録し、使っているプレフィックスの数だけ別便で送る。通常の数は定期便にもできるが、最後の一つが消えた知らせには待ち時間を認めない。

2026年10月28日
IPv4アドレスを持たない翻訳装置でも、エラーは帰さなければならない

IETF

IPv4アドレスを持たない翻訳装置でも、エラーは帰さなければならない

IPv6 の区間で生じたエラーを IPv4 側へ返すとき、翻訳装置が差出人の IPv6 アドレスを IPv4 に変換できないことがある。装置自身にも公開 IPv4 アドレスがなければ、返信の送信元欄は空白のままだ。v6ops の新しい草案は、その欄を埋める順番を定めた。公開 IPv4 が使えるならそれを先に使い、なければ予約済みの`192.0.0.8`を使う。元の IPv6 アドレスは別の Node Identification 拡張に載せる。エラーを届けることと発信したノードを示すことを、一つの数字に押し込まない設計だ。

2026年10月28日
データは引っ越せる。古いサーバーの権限は持ち込めない。

IETF

データは引っ越せる。古いサーバーの権限は持ち込めない。

メールや予定表を持って別のサービスへ移るなら、箱を受け取る側にも仕事がある。箱の中にはファイルだけでなく、保存先を指す名前や権限の情報も入るからだ。10月28日に更新された IETF の個人データ移行用アーカイブ草案は、受け手がデータを扱いながら、送り手のファイル管理権限を受け継がないための境界を具体化した。

2026年10月28日
データを運ぶ箱は決まった。引っ越し先の権限は誰が決めるのか

IETF

データを運ぶ箱は決まった。引っ越し先の権限は誰が決めるのか

個人データの引っ越しでは、送り出す側の「全件エクスポート」と、受け入れる側の「元どおり使える」は別の検査項目だ。メールのフォルダーが二つのファイルに分かれれば、受け手は同じフォルダーだと認識しなければならない。共有相手が書かれていても、それを新しいサービスのアクセス権に即座に変えてはいけない。IETF の個人データ可搬アーカイブ草案は、この地味で高価な境界に踏み込んだ。持ち出せることと、持ち込んだ後に誰が扉を開けるかは、同じ権利ではない。

2026年10月28日
削除は受け付けた。では、名簿のどこを見ればいい?

IETF

削除は受け付けた。では、名簿のどこを見ればいい?

グループから一人を外す操作が成功しても、管理者の仕事は終わらない。実際の名簿を読み返して初めて、権限が消えたと確かめられる。10月28日に公開された SCIM の個人 Internet-Draft は、大規模なグループでその読み返しが難しくなる問題を取り上げた。提案は、グループとメンバーの関係を一件ずつ扱う新しい資源に移す。

2026年10月28日
MPLSの二段目の住所がない。三段目を繰り上げてはいけない

IETF

MPLSの二段目の住所がない。三段目を繰り上げてはいけない

三段の MPLS ラベルを観測したのに、二段目の次ホップだけ分からない。表をきれいにしたい人は、三段目の値を二段目に詰めたくなる。10月28日に提出された IPFIX の個人草案は、その一手を禁じる。途中のアドレスやプレフィックス長が欠けたら、同じ属性の深い段も出力を止める。空欄は調べられる。偽の段番号は、調査そのものを別の装置へ向かわせる。

2026年10月28日
同じURLで取りに行く。証明の有効期限は返事が持つ。

IETF

同じURLで取りに行く。証明の有効期限は返事が持つ。

書類棚の番地は変わらなくても、中の書類には期限がある。遠隔認証ではこの平凡な区別が厄介だ。端末が今出す証拠には鮮度が要る。一方、評価に使う保証情報や参照値は何度も取り出したい。IETF の作業部会草案は、新しい付録で両者の時計を分けて描いた。

2026年10月28日
RFC 10066でPCEP経路は複数化する。ヘッドエンドには拒否権がある

IETF

RFC 10066でPCEP経路は複数化する。ヘッドエンドには拒否権がある

制御装置が四つの経路を計算しても、入口のルーターが二つしか収容できなければ、残りは絵に描いた経路だ。新しい RFC は、計算能力と実装容量を別々に申告させる。

2026年10月28日
電池を節約するRPL草案が、先に番号を二つ使い回した

IETF

電池を節約するRPL草案が、先に番号を二つ使い回した

経路を知りたい端末が一度声を上げる。返事をするのは周囲のルーターで、電波と電池を払うのも彼らだ。IETF の ROLL 作業部会は、この請求書を小さくする草案を進めている。ところが新しい応答制御に欲しい二つの番号は、IANA の台帳ではすでに別の仕事に就いている。省エネの仕組みは、まず番号の会計を直さなければ始まらない。

2026年10月28日
結論は通せる。それでも「検証済み」の判は押せない

IETF

結論は通せる。それでも「検証済み」の判は押せない

審査書類に丸い印が一つあれば、会議は早く終わる。困るのは、その印が何を確かめたのか後から聞かれたときだ。IETF に出された新しい個人草案は、結論を運ぶ書式と、受け手が自分で証拠を調べる手順を分けた。

2026年10月28日
電波が届くことと、持ち主を調べる資格は別だ

IETF

電波が届くことと、持ち主を調べる資格は別だ

身の回りで見知らぬ位置情報タグが見つかったとき、持ち主を知る手掛かりは切実だ。一方、落としただけのタグから誰でも持ち主を割り出せるなら、防犯機能が別の追跡手段になる。IETF の DULT 作業部会草案は、この二つを同じ問い合わせ経路の問題として扱う。焦点は、Bluetooth で検知したのか、実物に近づいて NFC で読んだのかという違いにある。

2026年10月28日
同じLANにつながれば、誰でもエージェント名簿に載れる

IETF

同じLANにつながれば、誰でもエージェント名簿に載れる

近くの AI エージェントを自動で探せれば、設定の手間は減る。だが名簿の入口には受付係がいない。共有リンクにいる機器は、自分の名前と案内先を自分で流せる。便利な発見機能を、利用を許す判断まで昇格させるかが争点になる。

2026年10月28日
RDAPの転送先は正しくても、質問の条件は届かない

IETF

RDAPの転送先は正しくても、質問の条件は届かない

登録情報を探す利用者が正しいサーバーに着いたとしても、最初に頼んだ答えを得られるとは限らない。途中の HTTP リダイレクトで、拡張機能のクエリーパラメータが外されることがある。IETF の現行作業部会草案は、この削除を単なる技術的な不具合として扱わない。最初のサーバーが、次のサーバーにその値を渡してよいか判断しなければならないからだ。

2026年10月28日
配布したファイルは分かる。配布を決めた人の署名はどこだ

IETF

配布したファイルは分かる。配布を決めた人の署名はどこだ

ビルドの記録と台帳の受領証は残っている。それでも「この版を出せ」と決めた人を、誰も後から指せないことがある。10月26日の IETF 個人草案は、その判断を配布されたファイルのハッシュに結びつけようとする。

2026年10月28日

会員ロック解除

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

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

Leadership Alliance 会員限定

Leadership Alliance 解説

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

Leadership Alliance に参加