Extensible YANG Model
for YANG-Push NotificationsINSA-LyonLyonFrancealex.huang-feng@insa-lyon.frINSA-LyonLyonFrancepierre.francois@insa-lyon.frSwisscomBinzring 17Zurich8045Switzerlandthomas.graf@swisscom.comHuaweibenoit.claise@huawei.comThis document defines a new extensible notification structure, defined in YANG,
for use in YANG-Push Notification messages enabling any YANG compatible encodings
such as XML, JSON or CBOR. Additionally, it defines two essential extensions to this
structure, the support of a hostname and a sequence number and the support of a
timestamp caracterizing the moment when the changed data was observed.YANG-Push allows publishers to send notifications to a
data collection. The YANG-Push receiver decodes the message and optionally validates
the header and the content before forwarding to the next process in the data collection
system.The notification container from YANG-Push is currently based on the XML model
from NETCONF Event Notifications . This model has
the drawback that only a single mandatory "eventTime" leaf is defined and does offer a way
to extend this header with new notification metadata.
Additionally, this XML model is only valid for XML-based environments. When messages
are encoded in other YANG encodings, such as JSON or CBOR
, validators cannot use YANG to validate
the message schema.YANG data consumer receiving notifications require additional notification metadata to
understand the full context of the received message. For example, in addition to the
timestamp of when the event was encoded, it is also important to know the timestamp when
the metrics were observed, the hostname that sourced the message, and have
sequence numbers in generated messages so that lost notification messages can be
detected in unreliable transports. This additional notification metadata is
also helpful to correlate the data with other sources of Network Telemetry information.For such reasons, this document proposes the following:
First, it provides an extensible YANG notification header allowing
implementors and IETF contributors to easily add new notification metadata to the
notification message.
Second, it provides the first crucial extensions enabling operators to
identify which network node publishes which YANG-Push messages and when the events
or metrics were observed on the network node.
And finally, it provides a way to enable and disable these extensions globally
at the server, making the coexistence of different YANG-Push and NETCONF Event
Notification possible.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
when, and only when,
they appear in all capitals, as shown here.
The terms "subscriber", "publisher", and "receiver" are used as
defined in .The terms "client" is used as
defined in for NETCONF and for RESTCONF.The terms "implementation-time information" and "runtime information" are used as
defined in .In addition, this document defines the following terms:Notification Metadata: Additional data describing the context of a notification that
is sent in each message, e.g. which node generated the messsage or at which
time the notification was published.Notification Envelope: YANG structure encapsulating the payload of a notification,
allowing the inclusion of metadata.This section shows the relationship to ,
, and . defines a mechanism for NETCONF nodes to
send notifications to a collector. These are the key relationships
between the current document and :
This document does not change the header defined by nor
update any behavior defined in .
Implementations of use the header defined in Section 2.2.1
of .
The co-existance of the notification model defined in and
the model defined in the current document is possible.
The co-existence is discussed in .
Subscribed Notifications defines a mechanism
on top of to stream notifications from
the NETCONF node. These are the key relationships between the current
document and :
Section 1.4 of states that the
solution uses the notification header defined in . This document proposes a new header, which
clients can enable and replace the previously defined. When this new header is used, notification
messages are encoded as defined in .
Section 2.4.2 of defines how a
YANG-Push subscription is defined via an the 'establish-subscription'
RPC. This document extends the RPCs from Subscribed Notifications
to support enabling the new header defined
in this document.
defines how YANG data is encoded in XML.
These are the key relationship points between the current document and
:
Section 7.16.2 of defines the XML encoding
of YANG notification. This document defines a new header for such notifications.
When a YANG-Push publisher implements the specifications
in this document with the XML encoding, the notifications
are encoded according to in this document.
defines how YANG data is encoded using JSON.
These are the key relationship points between the current document and
:
does not define explicitly how a YANG
notification should be encoded using JSON encoding. This document
specifies a new header for such notifications.
When a YANG-Push publisher implements the specifications
in this document with JSON encoding, the notifications
are encoded according to in this document.
defines how YANG data is encoded using CBOR.
These are the key relationship points between the current document and
:
does not define explicitly how a YANG
notification should be encoded using CBOR encoding.
When a YANG-Push publisher implements the specifications
in this document in CBOR encoding, the notifications
are encoded according to in this document.
Section 4.2.10 of defines the encoding of YANG notifications.
A notification is created by defining a 'notification' statement in the YANG module.
When a NETCONF server sends this notification, it is composed of two parts: a header
containing notification metadata which encapsulates the content and the content defined
by the 'notification' statement.In YANG 1.1 , the notification header is based on the model
defined in which contains a single metadata 'eventTime'
leaf. An example extracted from is shown in the following XML:2007-09-01T10:00:00Zso-1/2/3.0updown
]]>This document defines a new notification header and enables extending
this header with new notification metadata.
The notification header and extensions defined in the following sections
are to be used in YANG-Push environments and
can be implemented with NETCONF
and RESTCONF . Thus, when enabled, this new header
replaces the notifications defined in Subscribed Notifications
and YANG-Push notifications globally for all the entire server. defines how a client enables the header defined in this document.
extends the model from to enable clients to discover the capability of using the new notification header
for both implementation-time information and runtime information.
Lastly, defines the new notification header and how
it is encoded using XML, JSON and CBOR.The use of the notification envelope defined in this document can be
enabled during the configuration of a YANG-Push subscription.
This document augments the "ietf-subscribed-notification" model
to support the configuration of "notification-envelope". When enabled, all the
notifications defined in Subscribed Notification and
YANG-Push are encoded as defined in .When the node 'enable-notification-envelope' is set to true, the notifications published
by a YANG-Push publisher MUST use the header defined in .
If any notification metadata is enabled during the configuration of the subscription, the
notification metadata nodes MUST be present in the header.
When this node is disabled, notifications are encoded following .
This node 'enable-notification-envelope' MUST be enabled and disabled via the RPC
'enable-notif-envelope' only. This node MUST be changed prior to the creation of any
Dynamic Subscriptions. If any Dynamic Subscription is sending YANG-Push notifications
at the time of modifying this node, the server MUST refuse the change and send an
'invalid-notification-envelope-config' error.When a client changes this node 'enable-notification-envelope', any new Dynamic
Subscriptions send YANG-Push notifications according to the new value of this node.
In Configured Subscriptions, when the node 'enable-notification-envelope' changes,
the YANG-Push subscription is restarted using the header defined by this node, i.e. encoded as
when enabled and using if disabled.A client can discover the support of 'notification-envelope' model through
the capabilities model defined in . This documents
extends the 'ietf-notification-capabilities' model with:
A container containing a leaf 'notification-envelope', stating that the YANG
notification can be encoded following the notification-envelope model.
A container 'metadata' containing all the supported extensions to this header.
Extensions are defined in .
The YANG models defined in augments the
'ietf-notification-capabilities' model with the leaf and container listed above.This model can be retrieved via a NETCONF <get> RPC.This section defines how YANG notifications are structured when
the notification envelope is enabled on YANG-Push subscriptions. The following sections
define how this model is encoded in XML, JSON and CBOR.
When a YANG-Push publisher uses the notification model defined in this document,
the notification is structured as follows:
The notification is encapsulated in a root "envelope" container.
The header of the notification contains the notification metadata that is enabled during
the configuration of the subscription as a child nodes of the root "notification-envelope"
container.
The content of the notification defined by the 'notification' statement is encoded
in the 'notification-contents' leaf.
The 'notification-contents' element SHOULD be located at the end of the notification envelop
structure.
The following YANG tree illustrates the notification envelope
supporting only the mandatory metadata 'event-time'.
See for more extensions to this header.
]]>The YANG notification can be encoded using XML ,
JSON and CBOR .A YANG notification encoded in XML is structured as a root
"envelope" container. The namespace of this container is the namespace
defined in the YANG module "ietf-yp-notification":Two mandatory child nodes within the "envelope" container are expected,
representing the event time and the notification
payload. The "event-time" node is defined
within the same XML namespace as the "envelope" container. The "event-time"
node MUST be compliant with . Other notification
metadata defined within the YANG module defined in MUST use the same XML namespace.
See for more details.When other notification metadata is enabled through configuration, the
supplementary nodes are encoded at the same level of the mandatory
"event-time" node and use the XML namespace defined in the YANG module.
The content of the notification that is defined by the 'notification'
statement is encoded in the "notification-contents" node.
The name and namespace of this payload element are determined by the
YANG module containing the 'notification' statement representing the
notification message.The following example shows a "push-update" notification defined
in the YANG module of YANG-Push encoded in XML:2024-10-10T10:59:55.32Z1011eth0up
]]>A YANG notification encoded in JSON is structured as a root
"envelope" container. The namespace of this container is the name of
the YANG module "ietf-yp-notification" defined in .Two mandatory child nodes within the "ietf-notification:envelope" container are expected,
representing the event time and the notification
payload. The "event-time" node is defined within the same namespace as the
"ietf-yp-notification:envelope" container and is compliant with
. Other metadata specified within the YANG module defined
in MUST use the same
namespace "ietf-yp-notification".When other notification metadata is enabled through configuration, the
supplementary nodes are encoded at the same level of the mandatory 'event-time'
node and use the YANG module name as its namespace.
See for more details.The content of the notification that is defined by the 'notification' statement is
encoded in the "notification-contents" node.
The name and namespace of this payload element are determined by the
YANG module containing the 'notification' statement representing the
notification message.The following example shows a "push-update" notification defined
in the YANG module of YANG-Push encoded in JSON:YANG notifications can be encoded in CBOR using Names or SIDs in keys.Notifications encoded using names is similar to JSON encoding as defined in
Section 3.3 of . The key of the element can be the name of
the element itself or be namespace-qualified. In the latter case, the namespace of the
notification container uses the YANG module name "ietf-yp-notification" defined
in .Notification encoded using YANG-SIDs replaces the names of
the keys of the CBOR encoded message for a 63 bit unsigned integer.
In this case, the keys of the encoded data use the SID value as defined in Section 3.2
of .
A SID allocation process is needed beforehand following .In the notification, two mandatory child nodes within the "ietf-yp-notification:envelope" container
are expected, representing the event time and the notification
payload. The "event-time" node is defined within the same namespace as the
"ietf-yp-notification:envelope" container and is compliant with .When other notification metadata is enabled through configuration, the
supplementary nodes are encoded at the same level of the mandatory "event-time"
node and use the YANG module name as its namespace when they are encoded as
names. When they are encoded using YANG SIDs, a SID value assigned to the
metadata node is used. See for more details.The content of the notification that is defined by the 'notification' statement is
encoded in the "notification-contents" node.
The name and namespace of this payload element are determined by the
YANG module containing the 'notification' statement representing the
notification message. Similarly, SIDs can be used as keys if they are well allocated. shows a "push-update" notification defined
in the YANG module of YANG-Push encoded in CBOR
using names as keys. The example uses the CBOR diagnostic notation as defined
in section 3.1 of :And shows the same notifcation encoded using SIDs:This section described two YANG notification header extensions
which are sent by default when the notification envelope is enabled.
When the envelope is enabled using the "enable-notification-envelope" node, the
publisher includes by default the "hostname" and "sequence-number" defined in the
following sections.
The client discovers the support of these two extension headers
with the mechanism defined in . When the extensions
defined in this document are supported by the server, the client discovers the presence
of these new metadata with the following augmentations in the 'ietf-notification-capabilities':
This document defines the following notification metadata as shown in the
following YANG tree . It also defines an extension to
the YANG-Push header. See the following sections for more
details.
]]>When YANG-Push notification messages are forwarded from a
receiver to another system, such as a message broker or a time series
database, the transport context is lost since it is not part of the
notification metadata of the notification container. Therefore, the downstream
system is unable to associate the message to the publishing process (the
exporting network node), nor able to detect message loss or reordering.To correlate network data among different Network Telemetry planes as
described in or among different
YANG-Push subscription types as defined in , a reference to the node streaming the data is
needed. This is essential for understanding the timely relationship
among these different planes and YANG-Push subscription types.Today, network operators work around this impediment by preserving
the transport source IP address and sequence numbers of the publishing
process. However, this implies encoding this information in the YANG-Push
notification messages which impacts the semantic readability of the
message in the downstream system.On top of that, the transport source IP address might not represent
the management IP address by which the YANG-Push publisher should be
known. In other terms, the source-host , which
is the "Address of the remote host for the session" might not be the
management IP address.To overcome these issues, this document proposes a notification
container extension with a hostname and a sequence number. This allows
the downstream system to not only be able to identify from which network
node, subscription, and time the message was published but also, the order
of the published messages.
hostname:
Describes the node's hostname according to the
'sysName' object definition in from where the
message was published from. This value is usually configured on the
node by the administrator to uniquely identify the node in the
network.
sequence-number:
Generates a unique sequence number for each published message by
the publisher process. The number counts up at every published
notification message as described in .
provides an example of
a JSON encoded, , "push-update"
notification message with hostname and sequence-number as extension.This section described two optional YANG push-update and push-change-update
notification header extensions which are enabled by default. The client discovers
the support of these two extension headers with the mechanism defined in .This document defines the following notification metadata as shown in the
following YANG tree . See the following sections for more
details.
| +--ro incomplete-update? empty
| +--ro ypot:timestamp? yang:date-and-time
| +--ro ypot:point-in-time? enumeration
+---n push-change-update {on-change}?
+--ro id? sn:subscription-id
+--ro datastore-changes
+--ro incomplete-update? empty
+--ro ypot:timestamp? yang:date-and-time
+--ro ypot:point-in-time? enumeration
]]>To correlate network data among different Network Telemetry planes as
described in Section 3.1 of or among different
YANG-Push subscription types defined in Section 3.1 of , observation timestamp describes when the state
change was observed or when the data was accounted. This is essential
for understanding the timely relationship among these different planes
and YANG push subscription types.With the delay
between the YANG Notification export and the arrival at the downstream
system storing the data can be measured. With observation timestamp
described in this document, the delay between the time of the network
observation and the data export of the YANG-Push publisher process can
be measured as well, extending the delay measurement scope from the time
the network observation and storing the data.When the time bucket length in a time series database and the
periodical YANG-Push subscription time is identical, the 'event-time' of
the netconf notification message header is used for indexing, there is
variable delay between the observation timestamp and the 'event-time', and
the anchor-time as described in Section 4.2 of
is close to the time bucket boundaries, a time bucket is going to have
periodically 0 or 2 measurements indexed instead of 1. Leading to
inconsistent accounting errors in the time series database. This problem
is resolved by using the observation timestamp instead of the 'event-time'
for time series database indexing.By extending YANG-Push Notifications with the observation timestamp
YANG object and a point-in-time enumeration for streaming update
YANG-Push notifications it is ensured that the observation timestamp is
always present with the best available time, it can be therefore used
unconditionally in the data processing chain and with the point-in-time
enumeration there is semantic describing at which point in time the
observation timestamp was observed.Besides the Subscription ID as described in Section 3.7 of , the following network observation time metadata
objects are part of "push-update" and "push-change-update"
notifications.
timestamp:
States the measurement observation time for the "push-update"
notification in a "periodical" and for the "push-change-update"
notification in a "on-change" subscription.By comparing the observation timestamp of two "push-update"
notifications in a periodical subscription, the collector can deduce
the actual cadence of the measurements, and compare it with the
subscription configuration. In case of an "on-change" subscription
it states the time when the network state change was observed.
point-in-time:
The enumeration states at which point in time the value of the
observation timestamp was observed. Choices are:current-accounting states for "periodical" subscriptions, the
point-in-time where the metrics are being polled and observed.initial-state states for "on-change sync on start" subscriptions,
the initial point in time when the subscription was established and
the state was observed.state-changed states for "on-change" and "on-change sync on
start" subscriptions, the point in time when the state change was
observed after the subscription was established.
provides an example
timeline of events to describe observation timestamp and point-in-time
for "on-change sync on start" subscriptions. At "T2" when the "on-change
sync on start" subscription is established, the timestamp of "T2" is
used in observation timestamp and "point-in-time" is set to
"initial-state". At "T3" and "T4" the timestamp of "T3" respectively
"T4" is used in observation timestamp and point-in-time is set to
"state-changed".
| (T1) Interface | (T2) YANG-Push | (T3) Interface | (T4) Interface
| state changed | "on-change sync | state changed | state changed
| to "Up". | on start" | to "Down". | to "Up".
| | subscription for | |
| | interface state | |
| | is established. | |
v v v v
]]> provides an example of
a JSON encoded, , "push-change-update"
notification message with as extension. provides an example
timeline of events to describe point-in-time for "periodical"
subscriptions. The timestamp of observation timestamp in "T2" is set at
the start of the polling of the YANG data store to "T2" and
point-in-time is set "current-accounting". At "T3" the timestamp of
observation timestamp of "T3" is used. At "T4" the timestamp of
observation timestamp of "T4" is used.
| (T1) YANG-Push | (T2) YANG-Push | (T3) YANG-Push | (T4) YANG-Push
| "periodical" | "periodical" | "periodical" | "periodical"
| subscription | current | current | current
| for interface | accounting | accounting. | accounting.
| counter is | | |
| established | | |
v v v v
]]> provides an example of
a JSON encoded, , "push-update"
notification message with as extension.TBD: explain co-existence with RFC5277The following sections shows the YANG tree and YANG module for the 'ietf-yp-notification' module.This YANG module extends "ietf-subscribed-notifications"
and "ietf-notification-capabilities" as shown in the
following YANG tree :
]]>The YANG module augments the module "ietf-subscribed-notifications" ,
augments the module "ietf-notification-capabilities" and
uses "ietf-yang-types" module and "ietf-yang-structure-ext" module .
WG List:
Authors: Alex Huang Feng
Pierre Francois
Thomas Graf
Benoit Claise
";
description
"Defines a notification header for Subscribed Notifications
[RFC8639] and YANG-Push [RFC8641]. When this notification header
is enabled through configuration, the root container of the
notification is encoded as defined in RFCXXX.
This module can be used to validate XML encoded notifications
[RFC7950], JSON encoded messages [RFC7951] and CBOR encoded
messages [RFC9254]. Refer to Section Y of RFC XXXX for more
details.
Copyright (c) 2024 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices.";
revision 2025-01-27 {
description
"First revision";
reference
"RFC XXXX: YANG-Push Notification Envelope";
}
identity notif-envelope-error {
description
"Base identify for errors found while attempting to
change configuration values during the
'enable-notif-envelope' RPC requests.";
}
identity invalid-notification-envelope-config {
base notif-envelope-error;
description
"This error is triggered and sent in the response of
the RPC 'enable-notif-envelope' when attempting to change
the value of the 'enable-notification-envelope' node
while any Dynamic Subscription is active. The node
'enable-notification-envelope' can only be changed prior to
the creation of the Dynamic Subscription.";
}
grouping notif-env-capabilities {
description
"This grouping defines the capabilities for
the notification-envelope defined in RFC XXXX
and the different supported metadata.";
leaf notification-envelope {
type boolean;
default false;
description
"Supports YANG-Push to use the notification-envelope
defined in RFC XXXX.";
}
container metadata {
description
"Container with the supported optional metadata by the
YANG-Push publisher.";
leaf hostname-sequence-number {
type boolean;
default false;
description
"Supports hostname and sequence-number
in the YANG-Push notifications as defined in the
YANG-Push notification-envelope in RFC XXXX.";
}
}
}
sx:structure envelope {
leaf event-time {
type yang:date-and-time;
mandatory true;
description
"The date and time the event was generated by the event
source. This parameter is of type dateTime and compliant
to [RFC3339].";
}
leaf hostname {
type inet:host;
description
"The hostname of the network node according to
[RFC1213]. This value is usually configured on the node
by the administrator to uniquely identify the node in
the network.";
}
leaf sequence-number {
type yang:counter32;
description
"Unique sequence number as described in [RFC9187] for each
published message.";
}
anydata notification-contents {
description
"This contains the values defined by the 'notification'
statement unchanged.";
}
}
// Subscription container
augment "/sn:subscriptions" {
description
"This augmentation adds the configuration switches for
enabling the notification envelope and metadatas.";
leaf enable-notification-envelope {
config false;
type boolean;
default false;
description
"Enables YANG-Push to use the notification-envelope
defined in RFC XXXX.";
}
container metadata {
config false;
description
"Container for configuring optional metadata.";
}
}
// RPCs
rpc enable-notif-envelope {
description
"This RPC allows a client to enable the notification envelope
globally for the server. When this option is enabled, all the YANG-Push
Notifications from all the subscriptions are encoded following
this structure.";
input {
leaf enable-notification-envelope {
type boolean;
default false;
description
"Enables YANG-Push to use the notification-envelope
defined in RFC XXXX.";
}
container metadata {
description
"Container for configuring optional metadata.";
}
}
}
// YANG-Push Capabilities extension
augment "/sysc:system-capabilities/notc:subscription-capabilities" {
description
"Extension to the subscription-capabilities model to enable
clients to learn whether the publisher supports the
notification-envelope";
container notification-metadata {
description
"Adds the notification metadata capabilities to subscription
capabilities.";
uses notif-env-capabilities;
}
}
}
]]>The following sections shows the YANG tree and YANG module for the 'ietf-yp-observation' module.This YANG module extends "ietf-yang-push"
and "ietf-notification-capabilities" as shown in the
following YANG tree :
The YANG module augments the module "ietf-yang-push" ,
augments the module "ietf-system-capabilities" .
WG List:
Authors: Thomas Graf
Benoit Claise
Alex Huang Feng
";
description
"Defines YANG-Push event notification header with the observation
time in streaming update notifications.
Copyright (c) 2024 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, is permitted pursuant to, and subject to the license
terms contained in, the Revised BSD License set forth in Section
4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the RFC
itself for full legal notices.";
revision 2024-12-17 {
description
"First revision";
reference
"RFC XXXX: Support of YANG-Push Notifications Observation Time";
}
feature yang-push-observation-timestamp {
description
"This feature indicates the YANG-push Notifications support
the observation timestamps in streaming update notifications.";
}
grouping yang-push-observation {
description
"This grouping adds the observation timestamp for the observed metrics.";
leaf timestamp {
type yang:date-and-time;
description
"This is the time when metrics were observed.";
}
leaf point-in-time {
type enumeration {
enum current-accounting {
description "For periodical subscriptions, the point-in-time
where the metrics are being polled and observed.";
}
enum initial-state {
description "For 'on-change sync on start' subscriptions, the
initial point in time when the subscription was established
and the state was observed.";
}
enum state-changed {
description "For 'on-change sync on start' subscriptions, the
point in time when the state change was observed after the
subscription was established.";
}
}
description
"This describes at which point in time the metrics were observed";
}
}
// Event notifications
augment "/yp:push-update" {
description
"This augmentation adds the observation timestamp of the accounted metrics
in the push-update notification.";
uses ypot:yang-push-observation;
}
augment "/yp:push-change-update" {
description
"This augmentation adds the observation timestamp of the event
in the push-change-update notification.";
uses ypot:yang-push-observation;
}
// Event capabilities
augment "/sysc:system-capabilities/notc:subscription-capabilities" {
description
"Add system level capabilities";
leaf yang-push-observation-supported {
if-feature "yang-push-observation-timestamp";
type boolean;
description
"Specifies whether the publisher supports exporting
observation-timestamp and point-in-time in notifications.";
reference
"RFC XXXX: YANG Notifications Observation Time";
}
}
}
]]>Note to the RFC-Editor: Please remove this section before
publishing.Huawei implemented in push-update and push-change-update notifications
the timestamp and point-in-time extension as described in
for a YANG-Push publisher on
UDP-based Transport
for Configured Subscriptions in their VRP platform.6WIND implemented in push-update and push-change-update notifications
the timestamp and point-in-time extension as described in
for a YANG-Push publisher on
UDP-based Transport
for Configured Subscriptions in their VSR platform.Cisco implemented in push-update and push-change-update notifications
the timestamp and point-in-time extension as described in
for a YANG-Push publisher on
UDP-based Transport for
Configured Subscriptions in their IOS XR platform.TBDThis document describes the URI used for the IETF XML Registry and
registers a new YANG module name.IANA is requested to add this document as a reference in the following
URI's in the IETF XML Registry.This document registers the following YANG modules in the YANG Module Names Registry, within the
"YANG Parameters" registry:IANA is requested to register a new ".sid" file in the "IETF YANG SID Registry":A ".sid" file is proposed in .The authors would like to thank Per Anderson, Andy Bierman, Carsten Bormann,
Mohamed Boucadair, Tom Petch, Jason Sterne, Kent Watsen and Rob Wilton for
their review and valuable comments.Extensible Markup Language (XML) 1.0 (Second Edition)W3CNote to the RFC-Editor: Please remove this section before publishing.For CBOR encoding using YANG-SIDs identifiers, a ".sid" file is requested
to IANA in .