Summary

  • 11月2日付のYANG-Push v2第01版では、変更通知のupdateに含まれない子ノードは受信側で従来値を保つ。削除するなら、その経路を指すdeleteが要る。
  • 周期収集や再同期はdeleteを送らない。受信側はスナップショット全体の完了を確認してから、欠落した購読対象を削除と判断する。

収集装置の台帳に三つの子ノードがある。届いた通知には二つしかない。この一件だけで三つ目を消す運用は、メッセージの種類を読まずに台帳を書き換える。第01版の原文は、その種類ごとに受信側の振る舞いを指定する。第00版には今回追加された7.2.1節がなく、presence containerとleaf-listの細かな処理は示されていなかった。IETFの文書記録はNETCONF作業部会の現行草案として掲載している。

変更通知のupdatesでは、各項目が対象経路を持ち、updateかdeleteの一方を選ぶ。届いたleafの値は旧値を置き換え、containerとキー付きlistは再帰的に更新される。部分的なupdateから子ノードが抜けても旧値は残る。実際に消すには、その子を指す別のdelete項目が必要だ。親の更新と同じ通知に同居できるが、一つの対象を同じ通知で更新と削除の両方に使うことはできない。

leaf-listでは差がさらに鋭い。一部の要素を追加、削除、並べ替えしてもリストが空にならない場合、発行側は現在の全要素を正しい順序で送る。受信側は旧リスト全体をその列で置き換える。個々の要素だけを対象に更新や削除を送る方式は認められない。最後の要素を除くときは、リストか祖先に明示的なdeleteを送る。大きな部分木の更新からleaf-listが省かれただけなら、旧リストは残る。presence containerは空でも存在を示し、変更通知での消滅には同じく明示的な削除が要る。

周期スナップショットは別の約束だ。複数の通知に分割されてもdeleteは使わず、completeまたはupdate-completeで収集が終わってから欠落を判断する。途中で消せば、次の断片に載るはずの値まで失う。判断対象は、その収集が扱う購読データに限られる。RFC 8641は従来のYANG-Pushを、RFC 8639は購読通知の仕組みを定める。今回の草案は、その上で台帳の更新操作を具体化した。

公式文書には、実機の送信者、受信者、分割されたスナップショットと処理前後の台帳を結んだ実測記録がない。その一連の記録があれば、実装が規則どおりに状態を変えるか確かめられる。