Dynamic Subscription to YANG Events and Datastores over NETCONF
Extracted elements (22)
Dynamic subscription lifecycle is tied to the NETCONF session rather than being independently managed, because NETCONF is connection-oriented; this simplifies state cleanup when subscribers disconnect abnormally.
The 'error-info' hint mechanism for establish-subscription and modify-subscription failures allows publishers to suggest viable alternative parameter values (e.g., an acceptable period), enabling subscribers to retry with corrected parameters without trial-and-error.
A publisher may concurrently support RFC 8639 dynamic subscription RPCs and RFC 5277 <create-subscription>, but a single NETCONF transport session cannot mix both; session-level exclusivity is enforced via operation-not-supported errors.
Publishers that support only RFC 8640 dynamic subscriptions and not RFC 5277 MUST NOT advertise the notification capability URI, preventing clients from attempting RFC 5277 subscriptions on that session.
A NETCONF publisher supporting event stream subscription via RFC 8639 MUST support the 'NETCONF' event stream identified in that document.
A single NETCONF transport session MUST NOT support both RFC 8640 dynamic subscriptions and a subscription established by the <create-subscription> RPC defined in RFC 5277.
A solution MUST reply with <rpc-error> containing error-tag 'operation-not-supported' if an 'establish-subscription' request is received on a NETCONF session where an RFC 5277 <create-subscription> has already successfully created a subscription.
For a dynamic subscription, any 'modify-subscription', 'delete-subscription', or 'resync-subscription' RPCs MUST be sent using the same NETCONF session upon which the referenced subscription was established.
For a dynamic subscription, if the NETCONF session involved with 'establish-subscription' terminates, the subscription MUST be terminated.
For dynamic subscriptions, all notification messages MUST use the NETCONF transport session used by the 'establish-subscription' RPC.
If a publisher supports RFC 8640 but not RFC 5277 subscriptions, the publisher MUST NOT advertise 'urn:ietf:params:netconf:capability:notification:1.0'.
Notification messages transported over NETCONF MUST be encoded in a <notification> message as defined in RFC 5277 Section 4, with <eventTime> populated with the event occurrence time.
The 'encode-xml' feature of RFC 8639 MUST be supported, indicating that XML is a valid encoding for RPCs, state change notifications, and subscribed content.
The yang-data included in 'error-info' SHOULD NOT include the optional leaf 'reason', as it would be redundant with information already placed in the 'error-app-tag'.
When an RPC error occurs, the NETCONF RPC reply MUST include an <rpc-error> element per RFC 6241 with 'error-type' of 'application', an 'error-tag' corresponding to the error identity, and an 'error-app-tag' in the form <modulename>:<identityname>.
Datastore-specific subscription error identities map to error-tags: cant-exclude→operation-not-supported, datastore-not-subscribable→invalid-value, on-change-unsupported→operation-not-supported, period-unsupported→invalid-value, update-too-big→too-big, unchanging-selection→operation-failed.
For 'establish-subscription' and 'modify-subscription' errors, an optional 'error-info' node may contain XML-encoded hints. For event stream targets these are establish-subscription-stream-error-info or modify-subscription-stream-error-info; for datastore targets, the corresponding datastore error-info structures.
RPC error responses map subscription error identities to error-tag values: dscp-unavailable→invalid-value, encoding-unsupported→invalid-value, filter-unsupported→invalid-value, insufficient-resources→resource-denied, no-such-subscription→invalid-value, replay-unsupported→operation-not-supported.
A buggy or compromised NETCONF subscriber may send numerous 'establish-subscription' requests causing subscriptions to accumulate and exhaust system resources. Publishers MAY terminate the underlying NETCONF session, or MAY suspend or terminate a subset of active subscriptions on that session to reclaim resources.
Notification messages are encoded in the <notification> XML element with namespace 'urn:ietf:params:xml:ns:netconf:notification:1.0', containing an <eventTime> child element and the event payload.
RPC error responses include <error-type>, <error-tag>, <error-severity>, and <error-app-tag> child elements within <rpc-error>, with <error-info> optionally containing yang-data hint structures.
The 'establish-subscription' RPC uses XML namespace 'urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications' and may include stream, stream-xpath-filter, dscp, and other subscription parameters as child elements.