Strategic Circle 向けブリーフィング
参加すると、ログイン後に戦略解説を閲覧できます。
ストラテジックサークルに参加ガバナンス / IETF
IETF
IETF は、あらゆるネットワークが動かすプロトコルを書いています。ドラフト、ワーキンググループの議論、公開された標準を追い、本番環境に届く前に運用者への影響を解説します。
グローバルプロトコルガバナンス相互運用性リスク
最新の報道
IETFの最新情報
1,656件の記事
IETF
IETFのメール移行は完了した。バウンス処理は止まった。
IETF は9月11日にメール基盤の移行完了を発表した。2週間後、事務局長は切替後の不具合、旧システムに隠れていた到達不能アドレスの滞留、そして根拠に疑いが出たため停止したバウンス処理を公表した。移行で最も重要だった判断は、どのコンテナを選ぶかではない。自動処理をいつ止めるかだった。
IETF
3人の支持は賛成票ではない――IETF上訴草案が置く全体審査の関門
改訂02は、IESG または IAB 全体による審査に必要な支持者を3人とし、3人未満でも審理できるという明文の選択肢を削除した。IESG から IAB へ進む段階では、最初の支持者が引き続き数えられる。Datatracker は個人提出の Internet-Draft として掲載している。
IETF
IETFが新しいTCPトンネルを承認。ゲートウェイに宿題が残る
新しい HTTP プロキシ方式は、TCP トンネルに固有のオリジンとパスを与える。IESG は草案を Proposed Standard として公表することを承認した。次は、各ゲートウェイが HTTP の各バージョン間で運べるようにする番だ。
IETF
利用を許された送信元アドレスでも、経路表になければ遮断される
パケットの行き先を知っていることと、顧客がその送信元アドレスを使う権限を知っていることは別の話だ。RFC 10078は、転送表に両方の答えを求めると何が起きるかを示している。
IETF
計算が最速のエッジ拠点でも、20ミリ秒の予算を超える
IETF のクラウド VR 例では、計算が最速の拠点を選ぶとエンドツーエンドの遅延予算を超える。計算とネットワークを合わせて評価したときだけ、20ミリ秒を下回る選択肢が見つかる。
IETF
PCEPは経路を対にできる。戻りの通信が動く証明まではできない
往路は生きているのに、復路の生存確認だけが落ちた。誰がサービス停止を宣言するのか。RFC 10067は経路を関連付けるが、その運用判定は管理層とオペレーターに残す。
IETF
番号18の次で止まった。Joe AbleyがRIPE 93で語ったEPPの関門
IANA が番号を登録しても、親ゾーンへ DS データを届ける受付は別にある。Joe Abley が RIPE 93で語ったのは、DNSSEC の切り替えが登録機関の EPP 手続きで足止めされる実態だった。
IETF
IETFがOIFに次期光モジュール仕様の共有を要請。引用した草案2本は失効中
IETF の CCAMP ワーキンググループは、将来の CMIS と C-CMIS に関する作業文書を OIF に共有するよう求めた。コントローラー向け YANG モデルを並行して更新するためだ。要請文は、モジュールの内側からホスト側へ出す情報の例に「搬送波の中心周波数」を挙げる。一方、進行中と記した光モジュール草案2本は、Datatracker ではすでに失効扱いになっている。
IETF
IETFのAI実験、許可の前に「終わり方」を書け
NMOP の改訂憲章案は、異常検知とインシデント管理に限って AI 実験を認める構想だ。開始前に範囲、終了条件、実装への責任を示し、作業部会のコンセンサスと Area Director の同意を求める。入口より先に出口を決める設計が、実際に機能するかが問われる。
IETF
弾性ルーティング案、戻す前に「戻った後」を確認せよという
混雑を避ける迂回路には手順がある。10月の改訂版が示した元の経路への復帰条件は、復帰が終わっていることを前提にしてしまった。
IETF
一人の失敗報告でタスク全体が失敗になる。ルールを決めるのは誰か
共同作業の担当者が一人、失敗を報告した。後続システムが受け取るのは、その人だけの記録とは限らない。RFC 10051では、`AUTOMATIC-FAILURE`を使うと、その応答がタスク全体の失敗につながることがある。誰の返答が、どの範囲の状態を変えるのか。ここがこの規格の運用上の焦点だ。
IETF
航空機は接続先を変える。BGP経路は航空ネットワークの外へ出さない。
飛行中の航空機が別の地上局につながるたびに、地上側は新しい宛先を知る必要がある。IETF 作業部会の草案は、その変化を航空向けの重ね合わせネットワーク内で扱い、継続的な BGP 接続を地上の安全な回線に置く。境界を守るのは、航空側と下位ネットワークの両方に接続するルーターの経路ポリシーだ。
IETF
SRv6の規則を断るPCEPエラー、その番号だけが空欄だ
経路制御装置が SRv6 アドレスの内部を指定し、ルーターに「この部分を見て通信を選べ」と命じる。10月28日付の提案は、無断の命令や壊れた命令をルーターが拒否する手順も書いた。ところが拒否を伝えるエラー値は `TBD_EV` のまま。番号の割り当て申請からも抜けている。
IETF
BGPの会話からIPが消えても、次ホップのMACには持ち主がいる
共有イーサネット上の BGP を QUIC で守る提案が出た。交換所が新しいフレームを通し、隣接ルーターが鍵で相手を確認する。ところが、その相手は経路の次ホップとして第三者の MAC を指定できる。会話を守る鍵だけで、転送先の持ち主までは決められない。
IETF
OAuthクライアントの出口IPは変わった。認可サーバーの門はまだ開かない。
新しい送信元アドレスを公開すれば、移行は終わり。そんな手順書ではトークン取得が止まる。10月28日の IETF 個人草案は、クライアントが示す IP 範囲と認可サーバーが実際に受け入れる範囲を別のものとして扱う。ファイルを書き換える権限と、門を開ける権限は同じではない。
IETF
炭素の数字に住所ができた。計器の証人はまだいない。
ウェブサイトが電力や排出量を決まった場所で公開すれば、機械は数字を拾いやすくなる。新しい草案はその場所と形式を提案する。しかし、拾いやすい数字は確かな数字と同義ではない。画面に緑の印を付ける側は、発表した人と測定した人、署名した人と検証した人を分けて示さなければならない。
IETF
「良い経路」の採点者は誰だ――SR Policyが重みを変える前に
一つの経路が傷み、別の経路には余裕がある。通信を自動で移せば済むように見える。10月の SR-TE 草案は、経路の損失や遅延などから品質点をつけ、Segment List の転送重みを変える仕組みを描く。だが、採点式は運用側が設定する。確立済みの RFC が重みから決めるのはフローの割合であって、アプリケーションの成功ではない。スコアがパケットを動かすとき、その数字を書いた人の判断も一緒に動く。
IETF
BGPが保証できるのは一つの境界だけ――次の狭い門には別の判断がある
あるルーターが自分の接続口を通れる IP パケットの大きさを知っていても、宛先までの全区間を知っているわけではない。十月二十八日の個人草案は、その接続口の値を BGP 経路に載せる案を示した。便利な数字ほど、誰がどの区間について約束したのかを忘れやすい。
IETF
PCEPで「停止」を送った。S-BFDが止まった証拠はどこにある
経路の故障検知を中央から切り替えられるなら便利だ。だが、PCE 作業部会の草案を読むと、停止の扱いだけが妙に騒がしい。ある節は B=0と一緒に届くパラメータを「無視してもよい」とし、別の節は「無視しなければならない」とする。さらに編集者注は、フィールドそのものを送らなければ削除する案を掲げる。制御器の画面が消灯しても、ルーターの検知器がどうなったかは別の記録が答える。
IETF
耐量子ACME草案が「厳格」を外した――古い署名を止める日付は誰が決める
六月案には、従来型の署名だけでは通さない「厳格」な設定があった。十月二十八日の改訂案では、その設定自体が消えた。証明書を発行するサーバーは新しい方式を備えながら、古い署名をいつまで受け入れるかを自ら決められる。「耐量子」という看板より、受付窓口の拒否規則が重要になった。
会員ロック解除
会員限定プロフィール分析
完全なプロフィール解説と詳細セクションを閲覧するには、ログインが必要です。
Leadership Alliance 解説
IP 資産の所有者と経営チームのために：アライアンス向け解説、非公開レポート、アナリストの直接サポート。
Leadership Alliance に参加