RFC 8639
Subscription to YANG Notifications
2.5. Configured Subscriptions
A configured subscription is a subscription installed via configuration. Configured subscriptions may be modified by any configuration client with the proper permissions. Subscriptions can be modified or terminated via configuration at any point during their lifetime. Multiple configured subscriptions MUST be supportable over a single transport session. Configured subscriptions have several characteristics distinguishing them from dynamic subscriptions: o persistence across publisher reboots, o persistence even when transport is unavailable, and o an ability to send notification messages to more than one receiver. (Note that receivers are unaware of the existence of any other receivers.) On the publisher, support for configured subscriptions is optional and advertised using the "configured" feature. On a receiver of a configured subscription, support for dynamic subscriptions is optional. However, if replaying missed event records is required for
a configured subscription, support for dynamic subscription is highly recommended. In this case, a separate dynamic subscription can be established to retransmit the missing event records. In addition to the subscription parameters available to dynamic subscriptions as described in Section 2.4.2, the following additional parameters are also available to configured subscriptions: o A "transport", which identifies the transport protocol to use to connect with all subscription receivers. o One or more receivers, each intended as the destination for event records. Note that each individual receiver is identifiable by its "name". o Optional parameters to identify where traffic should egress a publisher: * A "source-interface", which identifies the egress interface to use from the publisher. Publisher support for this parameter is optional and advertised using the "interface-designation" feature. * A "source-address" address, which identifies the IP address to stamp on notification messages destined for the receiver. * A "source-vrf", which identifies the Virtual Routing and Forwarding (VRF) instance on which to reach receivers. This VRF is a network instance as defined in [RFC8529]. Publisher support for VRFs is optional and advertised using the "supports-vrf" feature. If none of the above parameters are set, notification messages MUST egress the publisher's default interface. A tree diagram that includes these parameters is provided in Figure 20 in Section 3.3. These parameters are described in the YANG module in Section 4.2.5.1. Configured Subscription State Machine
Below is the state machine for a configured subscription on the publisher. This state machine describes the three states ("valid", "invalid", and "concluded") as well as the transitions between these states. Start and end states are depicted to reflect configured subscription creation and deletion events. The creation or modification of a configured subscription initiates an evaluation by the publisher to determine if the subscription is in the
"valid" state or the "invalid" state. The publisher uses its own criteria in making this determination. If in the "valid" state, the subscription becomes operational. See (1) in the diagram below. ......... : start :-. :.......: | create .---modify-----.----------------------------------. | | | | V V .-------. ....... .---------. .----[evaluate]--no--->|invalid|-delete->: end :<-delete-|concluded| | '-------' :.....: '---------' |-[evaluate]--no-(2). ^ ^ ^ | ^ | | | | yes | '->unsupportable delete stop-time | modify (subscription- (subscription- (subscription- | | terminated*) terminated*) concluded*) | | | | | (1) | (3) (4) (5) | .---------------------------------------------------------------. '-->| valid | '---------------------------------------------------------------' Legend: Dotted boxes: subscription added or removed via configuration Dashed boxes: states for a subscription [evaluate]: decision point on whether the subscription is supportable (*): resulting subscription state change notification Figure 8: Publisher's State Machine for a Configured Subscription A subscription in the "valid" state may move to the "invalid" state in one of two ways. First, it may be modified in a way that fails a re-evaluation. See (2) in the diagram. Second, the publisher might determine that the subscription is no longer supportable. This could be because of an unexpected but sustained increase in an event stream's event records, degraded CPU capacity, a more complex referenced filter, or other subscriptions that have usurped resources. See (3) in the diagram. No matter the case, a "subscription-terminated" notification is sent to any receivers in the "active" or "suspended" state. A subscription in the "valid" state may also transition to the "concluded" state via (5) if a configured stop time has been reached. In this case, a "subscription-concluded" notification is sent to any receivers in the "active" or "suspended" state. Finally, a subscription may be deleted by configuration (4).
When a subscription is in the "valid" state, a publisher will attempt to connect with all receivers of a configured subscription and deliver notification messages. Below is the state machine for each receiver of a configured subscription. This receiver state machine is fully contained in the state machine of the configured subscription and is only relevant when the configured subscription is in the "valid" state. .-----------------------------------------------------------------. | valid | | .----------. .------------. | | | receiver |---timeout---------------->| receiver | | | |connecting|<----------------reset--(c)|disconnected| | | | |<-transport '------------' | | '----------' loss,reset------------------------------. | | (a) | | | | subscription- (b) (b) | | started* .--------. .---------. | | '----->| |(d)-insufficient CPU,------->| | | | |receiver| buffer overflow |receiver | | | subscription-| active | |suspended| | | modified* | |<----CPU, b/w sufficient,-(e)| | | | '---->'--------' subscription-modified* '---------' | '-----------------------------------------------------------------' Legend: Dashed boxes that include the word "receiver" show the possible states for an individual receiver of a valid configured subscription. * indicates a subscription state change notification Figure 9: Receiver State Machine for a Configured Subscription on a Publisher When a configured subscription first moves to the "valid" state, the "state" leaf of each receiver is initialized to the "connecting" state. If transport connectivity is not available to any receivers and there are any notification messages to deliver, a transport session is established (e.g., per [RFC8071]). Individual receivers are moved to the "active" state when a "subscription-started" subscription state change notification is successfully passed to that receiver (a). Event records are only sent to active receivers. Receivers of a configured subscription remain active on the publisher if both (1) transport connectivity to the receiver is active and (2) event records are not being dropped due to a publisher's sending capacity being reached. In addition, a configured subscription's receiver MUST be moved to the "connecting" state if the receiver is
reset via the "reset" action (b), (c). For more on the "reset" action, see Section 2.5.5. If transport connectivity cannot be achieved while in the "connecting" state, the receiver MAY be moved to the "disconnected" state. A configured subscription's receiver MUST be moved to the "suspended" state if there is transport connectivity between the publisher and receiver but (1) delivery of notification messages is failing due to a publisher's buffer capacity being reached or (2) notification messages cannot be generated for that receiver due to insufficient CPU (d). This is indicated to the receiver by the "subscription- suspended" subscription state change notification. A configured subscription's receiver MUST be returned to the "active" state from the "suspended" state when notification messages can be generated, bandwidth is sufficient to handle the notification messages, and a receiver has successfully been sent a "subscription- resumed" or "subscription-modified" subscription state change notification (e). The choice as to which of these two subscription state change notifications is sent is determined by whether the subscription was modified during the period of suspension. Modification of a configured subscription is possible at any time. A "subscription-modified" subscription state change notification will be sent to all active receivers, immediately followed by notification messages conforming to the new parameters. Suspended receivers will also be informed of the modification. However, this notification will await the end of the suspension for that receiver (e). The mechanisms described above are mirrored in the RPCs and notifications defined in this document. It should be noted that these RPCs and notifications have been designed to be extensible and allow subscriptions into targets other than event streams. For instance, the YANG module defined in Section 5 of [RFC8641] augments "/sn:modify-subscription/sn:input/sn:target".2.5.2. Creating a Configured Subscription
Configured subscriptions are established using configuration operations against the top-level "subscriptions" subtree. Because there is no explicit association with an existing transport session, configuration operations MUST include additional parameters beyond those of dynamic subscriptions. These parameters identify each receiver, how to connect with that receiver, and possibly whether the notification messages need to come from a specific egress
interface on the publisher. Receiver-specific transport connectivity parameters MUST be configured via transport-specific augmentations to this specification. See Section 2.5.7 for details. After a subscription is successfully established, the publisher immediately sends a "subscription-started" subscription state change notification to each receiver. It is quite possible that upon configuration, reboot, or even steady-state operations, a transport session may not be currently available to the receiver. In this case, when there is something to transport for an active subscription, transport-specific "call home" operations [RFC8071] will be used to establish the connection. When transport connectivity is available, notification messages may then be pushed. With active configured subscriptions, it is allowable to buffer event records even after a "subscription-started" has been sent. However, if events are lost (rather than just delayed) due to replay buffer capacity being reached, a new "subscription-started" must be sent. This new "subscription-started" indicates an event record discontinuity. To see an example of subscription creation using configuration operations over NETCONF, see Appendix A.2.5.3. Modifying a Configured Subscription
Configured subscriptions can be modified using configuration operations against the top-level "subscriptions" subtree. If the modification involves adding receivers, added receivers are placed in the "connecting" state. If a receiver is removed, the subscription state change notification "subscription-terminated" is sent to that receiver if that receiver is active or suspended. If the modification involves changing the policies for the subscription, the publisher sends to currently active receivers a "subscription-modified" notification. For any suspended receivers, a "subscription-modified" notification will be delayed until the receiver's subscription has been resumed. (Note: In this case, the "subscription-modified" notification informs the receiver that the subscription has been resumed, so no additional "subscription- resumed" need be sent. Also note that if multiple modifications have occurred during the suspension, only the "subscription-modified" notification describing the latest one need be sent to the receiver.)
2.5.4. Deleting a Configured Subscription
Subscriptions can be deleted through configuration against the top-level "subscriptions" subtree. Immediately after a subscription is successfully deleted, the publisher sends to all receivers of that subscription a subscription state change notification stating that the subscription has ended (i.e., "subscription-terminated").2.5.5. Resetting a Configured Subscription's Receiver
It is possible that a configured subscription to a receiver needs to be reset. This is accomplished via the "reset" action in the YANG module at "/subscriptions/subscription/receivers/receiver/reset". This action may be useful in cases where a publisher has timed out trying to reach a receiver. When such a reset occurs, a transport session will be initiated if necessary, and a new "subscription- started" notification will be sent. This action does not have any effect on transport connectivity if the needed connectivity already exists.2.5.6. Replay for a Configured Subscription
It is possible to do replay on a configured subscription. This is supported via the configuration of the "configured-replay" object on the subscription. The setting of this object enables the streaming of the buffered event records for the subscribed event stream. All buffered event records that have been retained since the last publisher restart will be sent to each configured receiver. Replay of event records created since restart is useful. It allows event records generated before transport connectivity establishment to be passed to a receiver. Setting the restart time as the earliest configured replay time precludes the possibility of resending event records that were logged prior to publisher restart. It also ensures that the same records will be sent to each configured receiver, regardless of the speed of transport connectivity establishment to each receiver. Finally, by establishing restart as the earliest potential time for event records to be included in notification messages, a well-understood timeframe for replay is defined. As a result, when any configured subscription's receivers become active, buffered event records will be sent immediately after the "subscription-started" notification. If the publisher knows the last event record sent to a receiver and the publisher has not rebooted, the next event record on the event stream that meets filtering criteria will be the leading event record sent. Otherwise, the
leading event record will be the first event record meeting filtering criteria subsequent to the latest of three different times: the "replay-log-creation-time", the "replay-log-aged-time", or the most recent publisher boot time. The "replay-log-creation-time" and "replay-log-aged-time" are discussed in Section 2.4.2.1. The most recent publisher boot time ensures that duplicate event records are not replayed from a previous time the publisher was booted. It is quite possible that a receiver might want to retrieve event records from an event stream prior to the latest boot. If such records exist where there is a configured replay, the publisher MUST send the time of the event record immediately preceding the "replay-start-time" in the "replay-previous-event-time" leaf. Through the existence of the "replay-previous-event-time", the receiver will know that earlier events prior to reboot exist. In addition, if the subscriber was previously receiving event records with the same subscription "id", the receiver can determine if there was a time gap where records generated on the publisher were not successfully received. And with this information, the receiver may choose to dynamically subscribe to retrieve any event records placed in the event stream before the most recent boot time. All other replay functionality remains the same as with dynamic subscriptions as described in Section 2.4.2.1.2.5.7. Transport Connectivity for a Configured Subscription
This specification is transport independent. However, supporting a configured subscription will often require the establishment of transport connectivity. And the parameters used for this transport connectivity establishment are transport specific. As a result, the YANG module defined in Section 4 is not able to directly define and expose these transport parameters. It is necessary for an implementation to support the connection establishment process. To support this function, the YANG data model defined in this document includes a node where transport-specific parameters for a particular receiver may be augmented. This node is "/subscriptions/subscription/receivers/receiver". By augmenting transport parameters from this node, system developers are able to incorporate the YANG objects necessary to support the transport connectivity establishment process. The result of this is the following requirement. A publisher supporting the feature "configured" MUST also support at least one YANG data model that augments transport connectivity parameters on "/subscriptions/subscription/receivers/receiver". For an example of such an augmentation, see Appendix A.
2.6. Event Record Delivery
Whether dynamic or configured, once a subscription has been set up, the publisher streams event records via notification messages per the terms of the subscription. For dynamic subscriptions, notification messages are sent over the session used to establish the subscription. For configured subscriptions, notification messages are sent over the connections specified by the transport and each receiver of a configured subscription. A notification message is sent to a receiver when an event record is not blocked by either the specified filter criteria or receiver permissions. This notification message MUST include an <eventTime> object, as shown in [RFC5277], Section 4. This <eventTime> MUST be at the top level of a YANG structured event record. The following example of XML [W3C.REC-xml-20081126], adapted from Section 4.2.10 of [RFC7950], illustrates a compliant message: <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <eventTime>2007-09-01T10:00:00Z</eventTime> <link-failure xmlns="https://acme.example.com/system"> <if-name>so-1/2/3.0</if-name> <if-admin-status>up</if-admin-status> <if-oper-status>down</if-oper-status> </link-failure> </notification> Figure 10: Subscribed Notification Message [RFC5277], Section 2.2.1 states that a notification message is to be sent to a subscriber that initiated a <create-subscription>. With this document, this statement from [RFC5277] should be more broadly interpreted to mean that notification messages can also be sent to a subscriber that initiated an "establish-subscription" or to a configured receiver that has been sent a "subscription-started". When a dynamic subscription has been started or modified with "establish-subscription" or "modify-subscription", respectively, event records matching the newly applied filter criteria MUST NOT be sent until after the RPC reply has been sent. When a configured subscription has been started or modified, event records matching the newly applied filter criteria MUST NOT be sent until after the "subscription-started" or "subscription-modified" notification has been sent, respectively.
2.7. Subscription State Change Notifications
In addition to sending event records to receivers, a publisher MUST also send subscription state change notifications when events related to subscription management have occurred. Subscription state change notifications are unlike other notifications in that they are never included in any event stream. Instead, they are inserted (as defined in this section) into the sequence of notification messages sent to a particular receiver. Subscription state change notifications cannot be dropped or filtered out, they cannot be stored in replay buffers, and they are delivered only to impacted receivers of a subscription. The identification of subscription state change notifications is easy to separate from other notification messages through the use of the YANG extension "subscription-state-notif". This extension tags a notification as a subscription state change notification. The complete set of subscription state change notifications is described in the following subsections.2.7.1. "subscription-started"
This notification indicates that a configured subscription has started, and event records may be sent. Included in this subscription state change notification are all the parameters of the subscription, except for (1) transport connection information for one or more receivers and (2) origin information indicating where notification messages will egress the publisher. Note that if a referenced filter from the "filters" container has been used in the subscription, the notification still provides the contents of that referenced filter under the "within-subscription" subtree. Note that for dynamic subscriptions, no "subscription-started" notifications are ever sent.
Below is a tree diagram for "subscription-started". All objects contained in this tree are described in the YANG module in Section 4. +---n subscription-started {configured}? +--ro id | subscription-id +--ro (target) | +--:(stream) | +--ro (stream-filter)? | | +--:(by-reference) | | | +--ro stream-filter-name | | | stream-filter-ref | | +--:(within-subscription) | | +--ro (filter-spec)? | | +--:(stream-subtree-filter) | | | +--ro stream-subtree-filter? <anydata> | | | {subtree}? | | +--:(stream-xpath-filter) | | +--ro stream-xpath-filter? yang:xpath1.0 | | {xpath}? | +--ro stream stream-ref | +--ro replay-start-time? | | yang:date-and-time {replay}? | +--ro replay-previous-event-time? | yang:date-and-time {replay}? +--ro stop-time? | yang:date-and-time +--ro dscp? inet:dscp | {dscp}? +--ro weighting? uint8 {qos}? +--ro dependency? | subscription-id {qos}? +--ro transport? transport | {configured}? +--ro encoding? encoding +--ro purpose? string {configured}? Figure 11: "subscription-started" Notification Tree Diagram2.7.2. "subscription-modified"
This notification indicates that a subscription has been modified by configuration operations. It is delivered directly after the last event records processed using the previous subscription parameters, and before any event records processed after the modification.
Below is a tree diagram for "subscription-modified". All objects contained in this tree are described in the YANG module in Section 4. +---n subscription-modified +--ro id | subscription-id +--ro (target) | +--:(stream) | +--ro (stream-filter)? | | +--:(by-reference) | | | +--ro stream-filter-name | | | stream-filter-ref | | +--:(within-subscription) | | +--ro (filter-spec)? | | +--:(stream-subtree-filter) | | | +--ro stream-subtree-filter? <anydata> | | | {subtree}? | | +--:(stream-xpath-filter) | | +--ro stream-xpath-filter? yang:xpath1.0 | | {xpath}? | +--ro stream stream-ref | +--ro replay-start-time? | yang:date-and-time {replay}? +--ro stop-time? | yang:date-and-time +--ro dscp? inet:dscp | {dscp}? +--ro weighting? uint8 {qos}? +--ro dependency? | subscription-id {qos}? +--ro transport? transport | {configured}? +--ro encoding? encoding +--ro purpose? string {configured}? Figure 12: "subscription-modified" Notification Tree Diagram A publisher most often sends this notification directly after the modification of any configuration parameters impacting a configured subscription. But it may also be sent at two other times: 1. If a configured subscription has been modified during the suspension of a receiver, the notification will be delayed until the receiver's suspension is lifted. In this situation, the notification indicates that the subscription has been both modified and resumed.
2. A "subscription-modified" subscription state change notification
MUST be sent if the contents of the filter identified by the
subscription's "stream-filter-ref" leaf have changed. This state
change notification is to be sent for a filter change impacting
any active receivers of a configured or dynamic subscription.
2.7.3. "subscription-terminated"
This notification indicates that no further event records for this
subscription should be expected from the publisher. A publisher may
terminate the sending of event records to a receiver for the
following reasons:
1. Configuration that removes a configured subscription, or a
"kill-subscription" RPC that ends a dynamic subscription. These
are identified via the reason "no-such-subscription".
2. A referenced filter is no longer accessible. This reason is
identified by the "filter-unavailable" identity.
3. The event stream referenced by a subscription is no longer
accessible by the receiver. This reason is identified by the
"stream-unavailable" identity.
4. A suspended subscription has exceeded some timeout. This reason
is identified by the "suspension-timeout" identity.
Each reason listed above derives from the "subscription-terminated-
reason" base identity specified in the YANG data model in this
document.
Below is a tree diagram for "subscription-terminated". All objects
contained in this tree are described in the YANG module in Section 4.
+---n subscription-terminated
+--ro id subscription-id
+--ro reason identityref
Figure 13: "subscription-terminated" Notification Tree Diagram
Note: This subscription state change notification MUST be sent to a
dynamic subscription's receiver when the subscription ends
unexpectedly. This might happen when a "kill-subscription" RPC is
successful or when some other event, not including reaching the
subscription's "stop-time", results in a publisher choosing to end
the subscription.
2.7.4. "subscription-suspended"
This notification indicates that a publisher has suspended the sending of event records to a receiver and also indicates the possible loss of events. Suspension happens when capacity constraints stop a publisher from serving a valid subscription. The two conditions where this is possible are: 1. "insufficient-resources", when a publisher is unable to produce the requested event stream of notification messages, and 2. "unsupportable-volume", when the bandwidth needed to get generated notification messages to a receiver exceeds a threshold. These conditions are encoded in the "reason" object. No further notifications will be sent until the subscription resumes or is terminated. Below is a tree diagram for "subscription-suspended". All objects contained in this tree are described in the YANG module in Section 4. +---n subscription-suspended +--ro id subscription-id +--ro reason identityref Figure 14: "subscription-suspended" Notification Tree Diagram2.7.5. "subscription-resumed"
This notification indicates that a previously suspended subscription has been resumed under the unmodified terms previously in place. Subscribed event records generated after the issuance of this subscription state change notification may now be sent. Below is a tree diagram for "subscription-resumed". All objects contained in this tree are described in the YANG module in Section 4. +---n subscription-resumed +--ro id subscription-id Figure 15: "subscription-resumed" Notification Tree Diagram
2.7.6. "subscription-completed"
This notification indicates that a subscription that includes a "stop-time" has successfully finished passing event records upon reaching that time. Below is a tree diagram for "subscription-completed". All objects contained in this tree are described in the YANG module in Section 4. +---n subscription-completed {configured}? +--ro id subscription-id Figure 16: "subscription-completed" Notification Tree Diagram2.7.7. "replay-completed"
This notification indicates that all of the event records prior to the current time have been passed to a receiver. It is sent before any notification messages containing an event record with a timestamp later than (1) the "stop-time" or (2) the subscription's start time. If a subscription does not contain a "stop-time" or has a "stop-time" that has not been reached, then after the "replay-completed" notification has been sent, additional event records will be sent in sequence as they arise naturally on the publisher. Below is a tree diagram for "replay-completed". All objects contained in this tree are described in the YANG module in Section 4. +---n replay-completed {replay}? +--ro id subscription-id Figure 17: "replay-completed" Notification Tree Diagram2.8. Subscription Monitoring
In the operational state datastore, the "subscriptions" container maintains the state of all dynamic subscriptions as well as all configured subscriptions. Using datastore retrieval operations [RFC8641] or subscribing to the "subscriptions" container (Section 3.3) allows the state of subscriptions and their connectivity to receivers to be monitored. Each subscription in the operational state datastore is represented as a list element. Included in this list are event counters for each receiver, the state of each receiver, and the subscription parameters currently in effect. The appearance of the leaf "configured- subscription-state" indicates that a particular subscription came
into being via configuration. This leaf also indicates whether the current state of that subscription is "valid", "invalid", or "concluded". To understand the flow of event records in a subscription, there are two counters available for each receiver. The first counter is "sent-event-records", which shows the number of events identified for sending to a receiver. The second counter is "excluded-event- records", which shows the number of event records not sent to a receiver. "excluded-event-records" shows the combined results of both access control and per-subscription filtering. For configured subscriptions, counters are reset whenever the subscription's state is evaluated as "valid" (see (1) in Figure 8). Dynamic subscriptions are removed from the operational state datastore once they expire (reaching "stop-time") or when they are terminated. While many subscription objects are shown as configurable, dynamic subscriptions are only included in the operational state datastore and as a result are not configurable.2.9. Support for the "ietf-subscribed-notifications" YANG Module
Publishers supporting this document MUST indicate support of the YANG module "ietf-subscribed-notifications" in the YANG library of the publisher. In addition, if supported, the optional features "encode-xml", "encode-json", "configured", "supports-vrf", "qos", "xpath", "subtree", "interface-designation", "dscp", and "replay" MUST be indicated.3. YANG Data Model Tree Diagrams
This section contains tree diagrams for nodes defined in Section 4. For tree diagrams of subscription state change notifications, see Section 2.7. For the tree diagrams for the RPCs, see Section 2.4.3.1. The "streams" Container
A publisher maintains a list of available event streams as operational data. This list contains both standardized and vendor-specific event streams. This enables subscribers to discover what streams a publisher supports.
Below is a tree diagram for the "streams" container. All objects contained in this tree are described in the YANG module in Section 4. +--ro streams +--ro stream* [name] +--ro name string +--ro description string +--ro replay-support? empty {replay}? +--ro replay-log-creation-time yang:date-and-time | {replay}? +--ro replay-log-aged-time? yang:date-and-time {replay}? Figure 18: "streams" Container Tree Diagram3.2. The "filters" Container
The "filters" container maintains a list of all subscription filters that persist outside the lifecycle of a single subscription. This enables predefined filters that may be referenced by more than one subscription. Below is a tree diagram for the "filters" container. All objects contained in this tree are described in the YANG module in Section 4. +--rw filters +--rw stream-filter* [name] +--rw name string +--rw (filter-spec)? +--:(stream-subtree-filter) | +--rw stream-subtree-filter? <anydata> {subtree}? +--:(stream-xpath-filter) +--rw stream-xpath-filter? yang:xpath1.0 {xpath}? Figure 19: "filters" Container Tree Diagram3.3. The "subscriptions" Container
The "subscriptions" container maintains a list of all subscriptions on a publisher, both configured and dynamic. It can be used to retrieve information about the subscriptions that a publisher is serving.
Below is a tree diagram for the "subscriptions" container. All objects contained in this tree are described in the YANG module in Section 4. +--rw subscriptions +--rw subscription* [id] +--rw id | subscription-id +--rw (target) | +--:(stream) | +--rw (stream-filter)? | | +--:(by-reference) | | | +--rw stream-filter-name | | | stream-filter-ref | | +--:(within-subscription) | | +--rw (filter-spec)? | | +--:(stream-subtree-filter) | | | +--rw stream-subtree-filter? <anydata> | | | {subtree}? | | +--:(stream-xpath-filter) | | +--rw stream-xpath-filter? | | yang:xpath1.0 {xpath}? | +--rw stream stream-ref | +--ro replay-start-time? | | yang:date-and-time {replay}? | +--rw configured-replay? empty | {configured,replay}? +--rw stop-time? | yang:date-and-time +--rw dscp? inet:dscp | {dscp}? +--rw weighting? uint8 {qos}? +--rw dependency? | subscription-id {qos}? +--rw transport? transport | {configured}? +--rw encoding? encoding +--rw purpose? string | {configured}?
+--rw (notification-message-origin)? {configured}? | +--:(interface-originated) | | +--rw source-interface? | | if:interface-ref {interface-designation}? | +--:(address-originated) | +--rw source-vrf? | | -> /ni:network-instances/network-instance/name | | {supports-vrf}? | +--rw source-address? | inet:ip-address-no-zone +--ro configured-subscription-state? enumeration | {configured}? +--rw receivers +--rw receiver* [name] +--rw name string +--ro sent-event-records? | yang:zero-based-counter64 +--ro excluded-event-records? | yang:zero-based-counter64 +--ro state enumeration +---x reset {configured}? +--ro output +--ro time yang:date-and-time Figure 20: "subscriptions" Container Tree Diagram
(page 37 continued on part 3)
