Summary

  • The 2 November YANG-Push v2 revision 01 says that an omitted descendant in an on-change update remains unchanged at the receiver. A removed node needs its own delete entry at the relevant target path.
  • A periodic or resynchronization collection works differently: it sends no delete entries, and the receiver may infer deletion from missing data only after the complete subscribed snapshot has arrived.

Picture a collector holding a tree of operational state. A new message updates its parent branch but leaves one old child out. Is that child gone? The answer depends on which kind of message crossed the wire. The new revision puts that choice in the record. Revision 00 lacked the new Section 7.2.1 on presence containers and leaf-lists; the November text spells out the receiver's state transition in detail. The IETF tracker dates the active NETCONF working-group draft to 2 November.

For an on-change notification, each updates entry names a target and carries either update or delete. Provided leaf values replace old ones, while a supplied container or keyed list entry updates recursively. A child left out of that partial payload stays as it was. To remove that child, the publisher must send a separate delete naming its path; it can put the delete beside other updates in the same notification. One target cannot occur twice in a notification, even as an update and a delete. The receiver gets an operation, not a license to fill the gaps with intuition.

The rule becomes more pointed for a leaf-list. When one member is added, removed or reordered and the list remains nonempty, the publisher sends the entire current sequence in an update for the list or an ancestor. The sequence replaces the receiver's previous sequence. It cannot issue an update or delete for an individual member. When the final member disappears, the publisher sends an explicit delete for the leaf-list or an ancestor. If the leaf-list is merely absent from a broader on-change update, its old sequence stays. A presence container follows the same deletion principle: its disappearance needs an explicit delete, even though an empty presence container must be included when it exists.

Periodic collection uses a different bargain. The publisher sends a snapshot, possibly across several notifications, and never uses delete entries in a periodic or resync message. The receiver infers what vanished only when complete or update-complete closes that collection. Before then, an omitted child may simply be waiting in the next piece. The inference covers only subscribed data in that collection. RFC 8641 supplies the earlier YANG-Push baseline, while RFC 8639 defines the subscribed-notification setting; revision 01 sharpens the event-record semantics that a collector must implement.

The draft contains no named publisher-to-receiver trace showing a leaf-list update, a separate deletion and the receiver's inventory before and after. Such a trace would expose whether the proposed semantics survive a real decoder and a split snapshot.