要約

  • 草案は生成時刻、hostname、発行プロセス単位の32ビット連番、観測時刻の意味を運べるようにするが、各フィールドは特定のスキーマと運用文脈に限られた主張である。
  • 自動化が通知を根拠に動くには、スキーマ、認証された主体、プロセスの時代区分、時計、購読、内容同一性、下流経路、権威ある結果を別々に確認しなければならない。

コレクターに整ったオブジェクトが届く。ルートは envelope、時刻は解釈でき、hostnameは想定したルーターに見える。番号は一つ前の続きで、contents 内のYANG-Push更新も問題なくデコードされた。ここで確実に言えるのは、そのインスタンスを読めたということだけだ。

2026年5月18日付の第05版草案は、現実的な欠落を埋めようとしている。RFC 5277の通知ヘッダーは必須の eventTime しか持たず、拡張できない。受信側がブローカーや時系列データベースへ転送すると、元のトランスポート文脈も失われやすい。そこで草案は、XML、JSON、CBORで表現できるYANG構造にメタデータとペイロードをまとめる。

Datatracker 上では、Proposed Standardを目指し、WG Chairの次の判断を待つNETCONF作業部会の有効なInternet-Draftである。RFCではない。価値は、いくつかの主張を機械可読にした点にある。主張の範囲を証拠より広げてはいけない。

スキーマが保証するのは形である

有効化された envelope は、必須の event-time、任意の hostname と sequence-number、anydata 型の contents を持つ。RFC 8791 が構造を、RFC 7951 と RFC 9254 がJSONとCBORを規定する。

検証で確認できるのは、読み込んだモデルに対するノード、型、名前空間、符号化の整合性だ。そのモデル一式が意図した版か、contents の内部まで検査したか、値が現実に正しいかは別問題である。2026年9月10日のDatatrackerはYANG検証に4件のエラーと2件の警告を表示した。一方、履歴には以前の yanglint と pyang がエラーなしだったとの記録があり、例示の anydata は検証対象外だったとも書かれている。日時と範囲が違い、どちらも実装の動作証明ではない。

スキーマ受領証には、モジュール版、feature、シリアライズ、namespaceまたはSID、検証器、読み込んだモデル、contents まで含む検証範囲を残す。

hostnameは自分自身を認証しない

草案は hostname を発行ノードの名前とし、ネットワーク内で一意だと説明する。YANG記述には、通常は管理者が設定する値だともある。管理された命名領域では優れた相関キーだが、資格証明ではない。

セキュリティ節はNETCONFまたはRESTCONFに安全なトランスポートと相互認証を求め、hostnameの露出がネットワーク調査や偽通知の注入に役立ちうると警告する。未認証経路で edge-17.example を読んでも、誰かがその文字列を入れたことしか分からない。

本人性の受領証は、認証済みpeerまたは署名鍵、証明書と鍵の時代、装置、発行プロセス、命名権限、購読の発行権限を結び付ける。RFC 8341 が示すように、アクセス権は内容をフィルターしたり破棄したりできる。認証と発行権限は同義ではない。

連番は一つのプロセス時代に属する

sequence-number は counter32 で、1から始まり、プロセスが通知を出すたびに増え、4294967295の次は0になる。既知で観測中のプロセス時代なら、欠番や逆転は断絶を示す有用な兆候だ。

しかし草案は永続的なepoch識別子も、再起動時の保存規則も定めない。受信側が914から見始めれば、それ以前の欠落は見えない。新しいプロセスが同じhostnameを名乗り、relayが損失、複製、並べ替えを起こし、カウンターは正当にwrapする。「欠番なし」は、宣言された主体とepochについて、保存した観測範囲に欠番を見なかった、という意味に限られる。

連続性の受領証には、認証済みプロセス、起動時点、最初の値、0の解釈、受信開始、relay経路、保存確認を結ぶ。

時刻ごとに答える問いが違う

event-time はイベント生成時刻で、草案ではメッセージを組み立て送信した時点と説明される。観測拡張の timestamp は定期測定または状態変化を観測した時点、point-in-time は current-accounting、initial-state、state-changed の違いを示す。

これは時間枠の直前に測り、直後に送った値を誤ったbucketへ入れる問題を軽減する。ただし形式は時計を保証しない。RFC 6991 の date-and-time は、時間帯不明の -00:00 も許す。小数秒があっても、NTP/PTP同期、UTC追跡、誤差上限、単調性の証拠にはならない。

観測、生成、anchor-time、到着、保存の時刻を分離し、それぞれ時計源と不確かさを添える必要がある。

capabilityは宣言であって実例ではない

RFC 9196 は実装時または実行時の能力公開を定める。第05版はenvelope、hostname/sequence、observation timeの対応表示を追加する。交渉には有用だ。

真のフラグが示すのは「対応可能」である。グローバル設定が現在オンか、この通知に任意フィールドがあったか、値が正しいか、すべての中間系が保持したかは証明しない。対応、設定、送出、保管は四つの状態だ。

設定変更はサーバー全体に効き、既存の動的・設定済み購読をすべて終了させ、旧ヘッダーで subscription-terminated を送る。ネットワークでは新旧形式が共存しうる。移行受領証には設定トランザクション、終了した購読、受信互換性、新epochが必要になる。

contents は購読条件を引き継ぐ

RFC 8639 は配送をフィルター、受信先、権限、ライフサイクルに結び付ける。RFC 8641 はperiodicとon-change、datastore、filter、anchor、dampening、同期を区別する。push-update の完全性は購読条件の内側だけにあり、push-change-update はdampening中の中間変化をまとめることがある。

Envelopeは契約全体を繰り返さない。Subscription IDは参照キーであり、生成時に効いていた版の証明ではない。filter、datastore、権限、trigger、receiverが変わってもhostnameと連番は滑らかなままになりうる。実効設定の暗号学的fingerprintと変更イベントを保存すべきだ。

RFC 8342 はintended、running、operational stateを分ける。あるdatastore表示の正確なシリアライズは、転送動作、サービス影響、利用者結果を保証しない。

下流の保管には内容同一性が要る

基本草案は contents を変更せず載せるとするが、内容署名は含まない。安全なNETCONFまたはRESTCONFが守るのは一つの接続である。デコード、再符号化、転送、集約、保存の後まで保証が自動で付いてくるわけではない。

YANG provenance草案 は、まさに contents を対象とするCOSE署名を提案する。同時に限界も明記する。署名時点の出所と完全性は守るが、鮮度、正当な署名者が作ったデータの正しさ、鍵の非侵害、全中間者の署名、Key IDと権威ある情報源の適切な対応までは保証しない。

内容受領証はdigest、正規化、シリアライズ、署名者、鍵方針、検証結果、鮮度、変換を残す。署名された観測が正しいかは独立に調べる。

八つの受領証は確実性を貸し借りしない

必要なのは、スキーマと検証範囲、認証主体、プロセス連続性、時計と不確かさ、購読と権限、内容同一性と署名、トランスポートと下流保管、権威あるdatastoreと独立結果である。

Envelopeはそれらを運びやすくする。hostnameが認証を、カウンターが永続履歴を、timestampが同期を、capabilityが実在を、正しいbyte列が運用上の真実を借りてはならない。