RFC 5277 lets a client subscribe to event notifications from a NETCONF server. The server confirms the subscription and then sends notifications as events occur, until the session ends or the subscription stops for some other reason. A subscription cannot be changed once created.
In simpler words: you subscribe to a node for some or all events, and the node tells you whenever one happens.
What changes
Very little, which is the point of the earlier design.
- Protocol: two new RPCs, create-subscription (sent to the node) and notification (received from it). Both join the RPC family and the operations enumeration.
- Session: either extend the session class and override what changes, or fold subscription handling into the same class. It depends on which is more practical.
- Everything else: nothing, structurally.
The one place to bend
Notifications are a different kind of traffic. They arrive unasked, and they should not wait behind a slow edit-config. Under load, it pays to allow two connections per node at all times: one for operations, one dedicated to notifications.
Closing thoughts
The series stayed away from depth on every topic and kept to structure and sequence. That leaves designers and implementers room to go deeper where their own requirements take them. If you have a better solution than the one here, I would love to read it.
"Wisdom is not a product of schooling but of the lifelong attempt to acquire it." Albert Einstein
References: RFC 6241, NETCONF · RFC 5277, NETCONF event notifications
Drafted in 2014
Updated for site in 2026