要約

  • 第21版では、Network Node Subscriptionを重複しないComponent Subscriptionへ分解する主体がPublisher Parentだと明記された。購読状態のMessage Publisher ID一覧には最低一件が必要になった。
  • Parentが通知するAgent一覧は、その時点の構成についての申告である。必要な全コンポーネントが選ばれ、各Agentが途切れず送信したことまでは証明しない。
  • 継続性の監査には、ノードの文脈、当時の発行元集合、プロセス固有ID、シーケンスの世代、必要なメッセージID、観測時刻、購読状態の履歴を組み合わせる必要がある。

Last Call中に直された主語

draft-ietf-netconf-distributed-notif-21 は2026年9月6日に提出された。NETCONFワーキンググループの文書で、9月8日までIETF Last Callに置かれている。標準化トラックを目指してIESGへ提出済みだが、今なおInternet-Draftであり、RFCでも登録完了でもない。

直前の第20版に対するIANAレビューは IANA - Not OK だった。無効なXML例と将来必要な登録が指摘され、第21版は引用符、登録文、セキュリティ節のYANGパスを修正した。その結果、状態は Version Changed - Review Needed になった。これは再審査が必要という意味で、承認済みという意味ではない。

運用上の核心は一語の変更にある。SubscriberはPublisher Parentに対してノード単位の購読を維持し、ParentがそれをComponent Subscriptionへ分解する。第20版はSubscriberが分解すると読めた。Subscriberは欲しいデータを指定する。一方、装置内のAgentと能力を把握しているのはParentだ。したがって、どのコンポーネントで要求を満たすかを決める権限も、欠落を説明する責任もParent側にある。

さらに購読状態の message-publisher-id リストへ min-elements 1 が加わった。空の発行元一覧はモデル上許されない。重要な受領証ではあるが、網羅性の証明書ではない。

購読IDは契約を束ねる

CollectorはSubscriberと一つ以上のReceiverに分けられる。要求はParentだけに届く。Parentはノードの通知能力を公開し、重複しないComponent Subscriptionを作り、Agentへ属性を渡し、全体の状態を管理する。Agentは同じNetwork Node Subscription IDとライフサイクルを引き継ぎ、担当データをReceiverへ直接送る。

このため、購読IDは一つの送信プロセスを示さない。複数の発行を論理契約として束ねるだけである。購読IDごとの総量が安定していても、一つのAgentが停止している可能性がある。静けさは需要減、構成変更、再起動、通信障害のどれでも起こり得る。

ParentとAgentの調整方法はドラフトの範囲外で、YANGスキーマの領域割り当ても実装依存だ。「重複しない」という条件は二重発行を抑えるが、必要な領域をすべて覆うことまでは保証しない。

申告、観測、稼働状態は別々に保つ

購読ライフサイクルの通知はすべてParentが発する。subscription-started と subscription-modified は現在のMessage Publisher ID一覧を示し、分解が変われば新しい一覧が通知される。この履歴は、Parentが何を有効とみなしたかを示す時点付きの申告として保存すべきだ。

比較すべき台帳は三つある。Parentが申告した集合、Receiverが実際に観測した集合、稼働中の装置で要求範囲に寄与すべき実体の集合である。最初の二つが一致しても、申告されたAgentをすべて見たことしか分からない。申告から漏れたラインカードや、誤って割り当てられたスキーマ領域は見つからない。

制御面の記号は運用上の現実を代替しない。Parentの申告は、インベントリ、能力、設定と照合されて初めて強い証拠になる。不一致を一つの正常ランプに潰してはならない。

連続性はプロセスごとに測る

各 push-update または push-change-update は、発行したプロセスのローカルなMessage Publisher IDを持てる。通知エンベロープのドラフトには、任意のホスト名と発行プロセス別シーケンス番号もある。32ビットの番号は1から始まり、4,294,967,295の後に周回し、0で周回を見える形にする。観測タイムスタンプは値を観測した時刻であり、事象発生、符号化、配送の時刻とは限らない。

Publisher IDは発言者、シーケンスは同じ世代の欠落、メッセージIDは重複、観測時刻は測定の位置を示す。購読状態履歴は、その瞬間に誰が発言すべきだったかを示す。プロセス再起動では新しい世代が始まり、遅延した旧メッセージが後から届くこともある。ローカルIDは別ノード間で衝突し得る。したがって、ノード、発行元、世代、状態の有効期間を一体で記録しなければならない。

同じアドレスの内側に複数の主体がいる

Receiverから見ると、全Agentは同じ送信元IPを使う。UDPでは同じL4ポートを共有し得る。HTTPSでは、この構成上、ソフトウェアプロセスごとに専用の送信元ポートが必要になる。五つ組やTLS終端は索引には便利でも、完全な出所証明ではない。

UDP通知のドラフトはMessage Publisher IDとMessage IDを組み合わせ、収集域でローカルIDが再利用される場合は送信元IPも必要になり得るとする。また、大きな通知をIPフラグメンテーションに頼って運んではならない。出所を特定できても最大メッセージを確実に受けられなければ、帰属可能な障害が再び無音の欠落になる。

直接発行は防御境界も分散させる

ラインカードやネットワークプロセッサから直接送れば、中央ルートプロセッサをデータ経路から外せる。しかし認証、認可、鍵更新、流量制御、資源制限も複数のプロセスへ広がる。NETCONF、RESTCONFの安全なトランスポートとNACMは引き続き重要だが、実際のIDと強制点は各配備で検証しなければならない。Parentにある規則だけで、直接送信する全Agentの執行を証明することはできない。

Publisher IDは内部配置も見せる。集合の変化から再起動、増設、再割り当てが推測できる。監査に役立つ情報は攻撃者の地図にもなり得る。生のプロセス構成を見られる範囲は限定しつつ、監査記録からIDそのものを取り除いてはいけない。

残るLast Call上の問い

本文は更新通知に発行元IDを含めることを求める一方、現在のYANGツリーではメッセージ単位の message-publisher-id が任意に見える。第21版の最低一件という制約は購読状態の一覧に対するもので、各更新に自動的には及ばない。これは欠陥が確定したという主張ではなく、レビュー時に明確化すべき問いである。出所のない更新をReceiverが拒否または隔離できる条件は何か。

実装試験では、一覧が空でないこと、各更新にIDがあること、そのIDが当時の集合に含まれることを別々に確認する必要がある。

対象範囲

資料が示すのは文書、改訂履歴、レビュー状態、参照仕様の契約だけである。ベンダー採用、適合実装、実ネットワークの欠落や遅延、事故、攻撃、性能向上は確認していない。エンベロープ、UDP、HTTPSの文書もドラフトである。

変わりにくい結論は、分解、申告、発行、観測、照合が別々の行為だということだ。一つのIDでそれらを同一視すると、責任の境界が消える。

出典