要約

  • Publisher ID、Message ID、分割番号、最終フラグ、受入れ窓は、受信者が何を組み立てたかを限定的に示す。観測開始前に消えたイベントまでは示さない。
  • 信頼できる判断には、通信関連付け、分割完全性、系列連続性、送信元、購読、時刻、負荷安全性、権威ある運用状態という八つの独立した受領証が要る。

セグメント 0 の後に 2 が届き、最後に 1 が届く。2 の L ビットから全体が三つだと分かり、受信者は順序を直して連結する。一つの通知が完成した。この成功は真実だが、その意味は狭い。

改訂26の本文 は 2026 年 7 月 29 日付で、管理された環境の設定済み購読に単方向 UDP 関連を定義する。一つの IP 非断片化データグラムには、一つのメッセージか一つのセグメントだけが入り、再送は期待されない。Datatracker はこれを NETCONF WG の活性な Internet-Draft、想定 Proposed Standard としており、履歴 は長い改訂過程を示す。まだ RFC ではない。

再構成が証明する範囲

同一メッセージの各セグメントは Message Publisher ID と Message ID を共有する。Segment Number は 0 から始まり周回せず、L は最後を示して期待総数を決める。受信者は順不同を扱い、重複を捨て、必要な集合を待ち、昇順に連結する。分割以外のオプションが必ず入るのは最初のセグメントだけである。

従って再構成は、あるヘッダー集合の下で一つのバイト列を得たことを示す。同番号の重複が同じ内容だったこと、最初のセグメントが置換されなかったこと、グループ化キーが一つの真正な送信期間に属したことまでは示さない。各セグメントと廃棄した重複のハッシュ、0..L の集合、先頭オプション、完成物のハッシュ、時間・メモリ上限を残すべきだ。

ドラフトは最低 96 KB の通知と、受信側で最低 64 セグメントを要求する一方、送信側には 64 未満、通常 10 秒以内、最長 20 秒の再構成を勧める。一片の欠落で全体が失われる。RFC 8900 が扱う IP 断片化の脆弱性は避けられても、損失の増幅は残る。

連続性は観測開始点より前を知らない

Message ID はランダムな 32 ビット値から始まり、一つずつ増え、最大値の後に 0 へ戻る。安定した送信期間内の欠番は損失を示せる。しかし最初に見えた ID より前に全メッセージが消えれば欠番はない。購読が有効になった時点で受信者が停止中の場合もある。プロセス再起動、ID 再利用、中継、受信停止、周回、受入れ窓の前進を記録しなければ「連続」は解釈できない。

RFC 8639 の sent-event-records と受信成功数の差は、同じ購読と期間なら未達を推定できる。ただし完成メッセージ内の重複や窓外廃棄は配送失敗に数えられない。重複、誤設定、攻撃を見失わない別カウンターが必要である。

相関キーと本人確認は違う

Message Publisher ID はノード内で局所的に一意なソフトウェアプロセス識別子である。収集域で一意性を保てなければ送信元 IP も使い、中継は区別を保存する。これは相関材料であり暗号学的本人確認ではない。下位層が保護しないネットワークでは安全な転送が必須で、ドラフトは DTLS を定める。RFC 9147 は DTLS 1.3 関連内の認証、完全性、リプレイ保護を提供する。

認証された相手であっても、その購読を発行する権限、再起動をまたぐプロセス同一性、元データストアの正当性は別である。RFC 8341 は管理認可を独立させる。機器、プロセス、資格情報の期間、ID 一意性の範囲、通信タプル、中継、窓判定、購読権限を結び付ける必要がある。

固定ヘッダーだけでは文脈が足りない

メディア種別は JSON、XML、CBOR、私的符号化を区別する。しかし対象、フィルター、周期または変更トリガー、抑制時間、受信者、設定版は購読側にある。RFC 8641 ではこれらが YANG-Push の意味を決める。ID が連続したまま購読が変われば、転送は正しくても意味が漂う。

イベント時刻、送信時刻、到着時刻、再構成完了時刻も同一ではない。Message ID 順は時計精度や管理対象での因果順を保証しない。時計源、誤差、各時刻、購読版を一枚の時間証拠に結ぶべきである。

UDP チェックサムと DTLS が正しいバイトを保護しても、YANG の単位、鮮度、意味は検証しない。RFC 8342 は running、intended、operational を区別する。送信プロセスに忠実な通知が、判断に必要な権威ある状態とは限らない。別経路で機器、経路、キュー、インターフェース、サービスを確認して初めて結論に届く。

経路への負担も完全性である

RFC 8085 は大量 UDP 利用を制限する。改訂26は予約容量と QoS を要求し、CS2、ペーシング、上限ある初期レートを勧める。通知が全て届いても、管理通信を圧迫したり受信メモリを枯渇させたりすれば運用上は失敗である。

必要な八つの受領証は、関連付け、完全な分割集合、系列、認証済み送信元、購読と符号化、時間、チェックサム・DTLS・レート・QoS、そして権威ある状態と独立結果である。

出典とレビューの境界

仕様背景は RFC 8639、RFC 8641、RFC 8342、RFC 8341、RFC 8085、RFC 8900、RFC 9147 である。過去の評価は 改訂23の TSVART が Ready with nits、改訂21の OPSDIR が Has issues、改訂20の YANG Doctors が On the right track だった。いずれも改訂26への最新判定ではない。