draft-ietf-netconf-notification-messages-05.txt   draft-ietf-netconf-notification-messages-06.txt 
NETCONF E. Voit NETCONF E. Voit
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track H. Birkholz Intended status: Standards Track H. Birkholz
Expires: August 19, 2019 Fraunhofer SIT Expires: February 16, 2020 Fraunhofer SIT
A. Bierman A. Bierman
YumaWorks YumaWorks
A. Clemm A. Clemm
Huawei Huawei
T. Jenkins T. Jenkins
Cisco Systems Cisco Systems
February 15, 2019 August 15, 2019
Notification Message Headers and Bundles Notification Message Headers and Bundles
draft-ietf-netconf-notification-messages-05 draft-ietf-netconf-notification-messages-06
Abstract Abstract
This document defines a new notification message format, using yang- This document defines a new notification message format. Included
data. Included are: are:
o a new notification mechanism and encoding to replace the one way o a new notification mechanism and encoding to replace the one way
operation of RFC-5277 operation of RFC-5277
o a set of common, transport agnostic message header objects. o a set of common, transport agnostic message header objects.
o how to bundle multiple event records into a single notification o how to bundle multiple event records into a single notification
message. message.
o how to ensure these new capabilities are only used with capable o how to ensure these new capabilities are only used with capable
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 19, 2019. This Internet-Draft will expire on February 16, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 26 skipping to change at page 2, line 26
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Header Objects . . . . . . . . . . . . . . . . . . . . . . . 3 3. Header Objects . . . . . . . . . . . . . . . . . . . . . . . 3
4. Encapsulation of Header Objects in Messages . . . . . . . . . 4 4. Encapsulation of Header Objects in Messages . . . . . . . . . 4
4.1. One Notification per Message . . . . . . . . . . . . . . 5 4.1. One Notification per Message . . . . . . . . . . . . . . 4
4.2. Many Notifications per Message . . . . . . . . . . . . . 5 4.2. Many Notifications per Message . . . . . . . . . . . . . 5
5. Configuration of Headers . . . . . . . . . . . . . . . . . . 8 5. Configuration of Headers . . . . . . . . . . . . . . . . . . 8
6. Discovering Receiver Support . . . . . . . . . . . . . . . . 9 6. Discovering Receiver Support . . . . . . . . . . . . . . . . 9
7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 18 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Changes between revisions . . . . . . . . . . . . . 20 Appendix A. Changes between revisions . . . . . . . . . . . . . 20
Appendix B. Issues being worked . . . . . . . . . . . . . . . . 21 Appendix B. Issues being worked . . . . . . . . . . . . . . . . 21
Appendix C. Subscription Specific Headers . . . . . . . . . . . 21 Appendix C. Subscription Specific Headers . . . . . . . . . . . 21
Appendix D. Implications to Existing RFCs . . . . . . . . . . . 22 Appendix D. Implications to Existing RFCs . . . . . . . . . . . 22
D.1. Implications to RFC-7950 . . . . . . . . . . . . . . . . 22 D.1. Implications to RFC-7950 . . . . . . . . . . . . . . . . 22
D.2. Implications to RFC-8040 . . . . . . . . . . . . . . . . 22 D.2. Implications to RFC-8040 . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Mechanisms to support subscription to event notifications and yang Mechanisms to support subscription to event notifications have been
datastore push are being defined in defined in [I-D.draft-ietf-netconf-subscribed-notifications] and
[I-D.draft-ietf-netconf-subscribed-notifications] and
[I-D.ietf-netconf-yang-push]. Work on those documents has shown that [I-D.ietf-netconf-yang-push]. Work on those documents has shown that
notifications described in [RFC7950] section 7.16 could benefit from notifications described in [RFC7950] section 7.16 could benefit from
transport independent headers. Communicating the following transport independent headers. With such headers, communicating the
information to receiving applications can be done without explicit following information to receiving applications can be done without
linkage to an underlying transport protocol: explicit linkage to an underlying transport protocol:
o the time information was generated o the time the notification was generated
o the time the information was placed in a message and queued for o the time the notification was placed in a message and queued for
transport transport
o a signature to verify authenticity o an identifier for the process generating the notification
o the process generating the information o signatures to verify authenticity
o an originating request correlation o a subscription id which allows a notification be correlated with a
request for that notification
o an ability to bundle information records into one a message o multiple notifications bundled into one transportable message
o the ability to check for message loss/reordering o a message-id allowing a receiver to check for message loss/
reordering
The document describes information elements needed for the functions The document describes information elements needed for the functions
above. It also provides YANG structures for sending messages above. It also provides instances of YANG structures
containing one or more events and/or update records to a receiver. [I-D.draft-ietf-netmod-yang-data-ext] for sending messages containing
one or more notifications to a receiver.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The definition of notification is in RFC 7950 [RFC7950]. Publisher, The definition of notification is in [RFC7950] Section 4.2.10.
receiver, subscription, and event occurence time are defined in Publisher, receiver, subscription, and event occurrence time are
[I-D.draft-ietf-netconf-subscribed-notifications]. defined in [I-D.draft-ietf-netconf-subscribed-notifications].
3. Header Objects 3. Header Objects
There are a number of transport independent headers which should have There are a number of transport independent headers which should have
common definition. These include: common definition. These include:
o subscription-id: provides a reference into the reason the o subscription-id: provides a reference into the reason the
publisher believed the receiver wishes to be notified of this publisher believed the receiver wishes to be notified of this
specific information. specific information.
o notification-time: the time an event, datastore update, or other o notification-time: the origination time where a notification was
item is recognized and recorded within the publisher. fully generated within the publisher.
o notification-id: Identifies the name of the notification, per the o notification-id: Identifies an instance of an emitted notification
YANG notification statement. May also provide the name of a yang- to a receiver.
data statement (whether transporting other types of messages is in
scope is tbd).
o observation-domain-id: identifies the publisher process which o observation-domain-id: identifies the publisher process which
discovered and recorded the event notification. (note: look to discovered and recorded the event notification. (note: look to
reuse the domains set up with IPFIX.) reuse the domains set up with IPFIX.)
o message-time: the time the message was packaged sent to the o message-time: the time the message was packaged sent to the
transport layer for delivery to the receiver. transport layer for delivery to the receiver.
o signature: allows an application to sign a message so that a o signature: allows an application to sign a message so that a
receiver can verify the authenticity of the message. receiver can verify the authenticity of the message.
skipping to change at page 4, line 44 skipping to change at page 4, line 45
application layer process. By exposing this object information as application layer process. By exposing this object information as
part of a header, and by using standardized object names, it becomes part of a header, and by using standardized object names, it becomes
possible for this object information to be leveraged in transit. possible for this object information to be leveraged in transit.
The objects defined in the previous section are these well-known The objects defined in the previous section are these well-known
header objects. These objects are identified within a dedicated header objects. These objects are identified within a dedicated
header subtree which leads off a particular transportable message. header subtree which leads off a particular transportable message.
This allows header objects to be easily be decoupled, stripped, and This allows header objects to be easily be decoupled, stripped, and
processed separately. processed separately.
There are two types of transportable messages: one format is used
when there is one notification being encapsulated, and another format
used when there are many notifications being bundled into one
message.
A receiver which supporting this document MUST be able to handle A receiver which supporting this document MUST be able to handle
receipt of either type of message from an publisher. It is possible receipt of either type of message from a publisher.
that changes between message types can occur without any prior
indication.
4.1. One Notification per Message 4.1. One Notification per Message
This section will be re-instated if NETCONF WG members are not This section has been deleted from previous versions. It will be re-
comfortable with the efficiency of the solution which can encode many instated if NETCONF WG members are not comfortable with the
notifications per message described below. efficiency of the solution which can encode many notifications per
message, as described below.
4.2. Many Notifications per Message 4.2. Many Notifications per Message
While possible in some scenarios, it often inefficient to marshal and While possible in some scenarios, it often inefficient to marshal and
transport every notification independently. Instead, scale and transport every notification independently. Instead, scale and
processing speed can be improved by placing multiple notifications processing speed can be improved by placing multiple notifications
into one transportable bundle. into one transportable bundle.
The format of this bundle appears in the yata-data tree below, and is The format of this bundle appears in the YANG structure below, and is
more completely defined in the yang module. There are three parts of fully defined in the YANG module. There are three parts of this
this bundle: bundle:
o a message header describing the marshaling, including information o a message header describing the marshaling, including information
such as when the marshaling occurred such as when the marshaling occurred
o a list of encapsulated information o a list of encapsulated information
o an optional message footer for whole-message signing and message- o an optional message footer for whole-message signing and message-
generator integrity verification. generator integrity verification.
Within the list of encapsulated notifications, there are also three Within the list of encapsulated notifications, there are also three
parts: parts:
o a notification header defining what is in an encapsulated o a notification header defining what is in an encapsulated
notification notification
o the actual notification itself o the actual notification itself
o an optional notification footer for individual notification o an optional notification footer for individual notification
signing and observation-domain integrity verification. signing and observation-domain integrity verification.
yang-data message structure message
+--ro message! +--ro message!
+--ro message-header +--ro message-header
| +--ro message-time yang:date-and-time | +--ro message-time yang:date-and-time
| +--ro message-id? uint32 | +--ro message-id? uint32
| +--ro message-generator-id? string | +--ro message-generator-id? string
| +--ro notification-count? uint16 | +--ro notification-count? uint16
+--ro notifications* +--ro notifications*
| +--ro notification-header | +--ro notification-header
| | +--ro notification-time yang:date-and-time | | +--ro notification-time yang:date-and-time
| | +--ro yang-module? yang:yang-identifier | | +--ro yang-module? yang:yang-identifier
| | +--ro yang-notification-name? notification-type
| | +--ro subscription-id* uint32 | | +--ro subscription-id* uint32
| | +--ro notification-id? uint32 | | +--ro notification-id? uint32
| | +--ro observation-domain-id? string | | +--ro observation-domain-id? string
| +--ro notification-contents? | +--ro notification-contents?
| +--ro notification-footer! | +--ro notification-footer!
| +--ro signature-algorithm string | +--ro signature-algorithm string
| +--ro signature-value string | +--ro signature-value string
| +--ro integrity-evidence? string | +--ro integrity-evidence? string
+--ro message-footer! +--ro message-footer!
+--ro signature-algorithm string +--ro signature-algorithm string
+--ro signature-value string +--ro signature-value string
+--ro integrity-evidence? string +--ro integrity-evidence? string
An XML instance of a message might look like: An XML instance of a message might look like:
<yang-data bundled-message <structure bundled-message
xmlns="urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0"> xmlns="urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0">
<message-header> <message-header>
<message-time> <message-time>
2017-02-14T00:00:05Z 2017-02-14T00:00:05Z
</message-time> </message-time>
<message-id> <message-id>
456 456
</message-id> </message-id>
<notification-count> <notification-count>
2 2
skipping to change at page 7, line 50 skipping to change at page 7, line 50
operation="delete"/> operation="delete"/>
</alpha> </alpha>
</datastore-changes-xml> </datastore-changes-xml>
</push-change-update> </push-change-update>
</notification-contents> </notification-contents>
</notification> </notification>
<notification> <notification>
...(record #2)... ...(record #2)...
</notification> </notification>
</notifications> </notifications>
</yang-data> </structure>
5. Configuration of Headers 5. Configuration of Headers
A publisher MUST select the set of headers to use within any A publisher MUST select the set of headers to use within any
particular message. The two mandatory headers which MUST always be particular message. The two mandatory headers which MUST always be
applied are 'message-time' and 'subscription-id' applied are 'message-time' and 'subscription-id'
Beyond these two mandatory headers, additional headers MAY be Beyond these two mandatory headers, additional headers MAY be
included. Configuration of what these optional headers should be can included. Configuration of what these optional headers should be can
come from the following sources: come from the following sources:
1. Publisher wide default headers for all notifications. These are 1. Publisher wide default headers which are placed on all
included if an optional header is inserted into 'additional- notifications. An optional header is a publisher default if its
headers' leaf-list shown in the yang tree below. identity is included within the 'additional-headers' leaf-list.
2. More notification specific headers may also be desired. If new 2. More notification specific headers may also be desired. If new
headers are needed for a specific type of YANG notification, headers are needed for a specific type of YANG notification,
these can be populated through 'additional-notification-headers' these can be populated through 'additional-notification-headers'
leaf-list. leaf-list.
3. An application process may also identify common headers to use 3. An application process may also identify common headers to use
when transporting notifications for a specific subscription. How when transporting notifications for a specific subscription. How
these are identified to a publisher is out-of-scope. such application specific configuration is accomplished within
the publisher is out-of-scope.
The set of headers used for any particular message is the superset of The set of headers selected and populated for any particular message
headers for the items listed above. is derived from the union of the mandatory headers and configured
optional headers.
The YANG tree showing elements of configuration is depicted in the The YANG tree showing elements of configuration is depicted in the
following figure. following figure.
module: ietf-notification-messages module: ietf-notification-messages
+--rw additional-default-headers {publisher}? +--rw additional-default-headers {publisher}?
+--rw additional-headers* optional-header +--rw additional-headers* optional-header
+--rw yang-notification-specific-default* +--rw yang-notification-specific-default*
| [yang-module yang-notification-name] | [yang-module yang-notification-name]
+--rw yang-module yang:yang-identifier +--rw yang-module yang:yang-identifier
skipping to change at page 9, line 36 skipping to change at page 9, line 36
</capabilities> </capabilities>
<session-id>4</session-id> <session-id>4</session-id>
</hello> </hello>
NOTE: It is understood that even though it is allowed in [RFC6241] NOTE: It is understood that even though it is allowed in [RFC6241]
section 8.1, robust NETCONF client driven capabilities exchange is section 8.1, robust NETCONF client driven capabilities exchange is
not something which is common in implementation. Therefore reviewers not something which is common in implementation. Therefore reviewers
are asked to submit alternative proposals to the mailing list. are asked to submit alternative proposals to the mailing list.
For RESTCONF, a mechanism for capability discovery is TBD. Proposals For RESTCONF, a mechanism for capability discovery is TBD. Proposals
are also welcome here. are welcome here.
The mechanism described above assumes that a capability discovery The mechanism described above assumes that a capability discovery
phase happens before a subscription is started. This is not always phase happens before a subscription is started. This is not always
the case. As an example, consider HTTP2 configured subscriptions the case. There is no guarantee that a capability exchange has taken
from section 3.1.3 of [I-D.draft-ietf-netconf-restconf-notif], there place before the messages are emitted. A solution for this in the
is no guarantee that a capability exchange has taken place before the case of HTTP based transport could be that a receiver would have to
updates are pushed. A solution for this could be that a receiver reply "ok" and also return the client capabilities as part a response
would reply "ok" and reply with the client capabilities as part of to the initiation of the POST.
the POST. (Or just use a different HTTP status code like 202 instead
of 200 'ok'). As such a requirement creates a new dependency for
[I-D.draft-ietf-netconf-restconf-notif] upon this specification, more
discussion is required to decide if this is a viable solution.
7. YANG Module 7. YANG Module
<CODE BEGINS> file "ietf-notification-messages@2018-01-31.yang" <CODE BEGINS> file "ietf-notification-messages@2019-08-16.yang"
module ietf-notification-messages { module ietf-notification-messages {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-notification-messages"; "urn:ietf:params:xml:ns:yang:ietf-notification-messages";
prefix nm; prefix nm;
import ietf-yang-types { prefix yang; } import ietf-yang-types { prefix yang; }
import ietf-restconf { prefix rc; } import ietf-yang-structure-ext { prefix sx; }
organization "IETF"; organization "IETF";
contact contact
"WG Web: <http://tools.ietf.org/wg/netconf/> "WG Web: <http://tools.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org> WG List: <mailto:netconf@ietf.org>
Editor: Eric Voit Editor: Eric Voit
<mailto:evoit@cisco.com> <mailto:evoit@cisco.com>
Editor: Henk Birkholz Editor: Henk Birkholz
skipping to change at page 10, line 39 skipping to change at page 10, line 31
Editor: Alexander Clemm Editor: Alexander Clemm
<mailto:ludwig@clemm.org> <mailto:ludwig@clemm.org>
Editor: Andy Bierman Editor: Andy Bierman
<mailto:andy@yumaworks.com> <mailto:andy@yumaworks.com>
Editor: Tim Jenkins Editor: Tim Jenkins
<mailto:timjenki@cisco.com>"; <mailto:timjenki@cisco.com>";
description description
"This module contains conceptual YANG specifications for yang-data "This module contains conceptual YANG specifications for
messages carrying notifications with well known header objects."; messages carrying notifications with well-known header objects.";
revision 2018-01-31 { revision 2019-08-16 {
description description
"Initial version."; "Initial version.";
reference reference
"draft-ietf-netconf-notification-messages-03"; "draft-ietf-netconf-notification-messages-06";
} }
/* /*
* FEATURES * FEATURES
*/ */
feature publisher { feature publisher {
description description
"This feature indicates that support for both publisher and "This feature indicates that support for both publisher and
receiver of messages complying to the specification."; receiver of messages complying to the specification.";
skipping to change at page 11, line 11 skipping to change at page 11, line 4
/* /*
* FEATURES * FEATURES
*/ */
feature publisher { feature publisher {
description description
"This feature indicates that support for both publisher and "This feature indicates that support for both publisher and
receiver of messages complying to the specification."; receiver of messages complying to the specification.";
} }
/* /*
* IDENTITIES * IDENTITIES
*/ */
/* Identities for common headers */ /* Identities for common headers */
identity common-header { identity common-header {
description description
"A well known header which can be included somewhere within a "A well-known header which can be included somewhere within a
message."; message.";
} }
identity message-time { identity message-time {
base common-header; base common-header;
description description
"Header information consisting of time the message headers were "Header information consisting of time the message headers were
placed generated prior to being sent to transport"; generated prior to being sent to transport";
} }
identity subscription-id { identity subscription-id {
base common-header; base common-header;
description description
"Header information consisting of the identifier of the "Header information consisting of the identifier of the
subscription associated with the notification being subscription associated with the notification being
encapsulated."; encapsulated.";
} }
identity notification-count { identity notification-count {
base common-header; base common-header;
description description
"Header information consisting of the quantity of notifications in "Header information consisting of the quantity of notifications in
a bundled-message for a specific receiver."; a bundled-message for a specific receiver.";
} }
identity optional-header { identity optional-header {
base common-header; base common-header;
description description
"A well known header which an application may choose to include "A well-known header which an application may choose to include
within a message."; within a message.";
} }
identity message-id { identity message-id {
base optional-header; base optional-header;
description description
"Header information that identifies a message to a specific "Header information that identifies a message to a specific
receiver"; receiver";
} }
identity message-generator-id { identity message-generator-id {
base optional-header; base optional-header;
description description
"Header information consisting of an identifier for a software "Header information consisting of an identifier for a software
entity which created the message (e.g., linecard 1)."; entity which created the message (e.g., linecard 1).";
} }
identity message-signature { identity message-signature {
base optional-header; base optional-header;
description description
skipping to change at page 12, line 22 skipping to change at page 12, line 15
base optional-header; base optional-header;
description description
"Header information consisting of an identifier for a software "Header information consisting of an identifier for a software
entity which created the message (e.g., linecard 1)."; entity which created the message (e.g., linecard 1).";
} }
identity message-signature { identity message-signature {
base optional-header; base optional-header;
description description
"Identifies two elements of header information consisting of a "Identifies two elements of header information consisting of a
signature and the signtature type for the contents of a message. signature and the signature type for the contents of a message.
Signatures can be useful for originating applications to Signatures can be useful for originating applications to
verify record contents even when shipping over unsecure verify record contents even when shipping over unsecure
transport."; transport.";
} }
identity message-integrity-evidence { identity message-integrity-evidence {
base optional-header; base optional-header;
description description
"Header information consisting of the information which backs up "Header information consisting of the information which backs up
the assertions made as to the validity of the information the assertions made as to the validity of the information
provided within the message."; provided within the message.";
} }
identity optional-notification-header { identity optional-notification-header {
base optional-header; base optional-header;
description description
"A well known header which an application may choose to include "A well-known header which an application may choose to include
within a message."; within a message.";
} }
identity notification-time { identity notification-time {
base optional-notification-header; base optional-notification-header;
description description
"Header information consisting of the time an originating process "Header information consisting of the time an originating process
created the notification."; created the notification.";
} }
identity notification-id { identity notification-id {
base optional-notification-header; base optional-notification-header;
description description
"Header information consisting of an identifier for an instance "Header information consisting of an identifier for an instance
of a notification egressing a publisher. "; of a notification. If access control based on a message's receiver may
strip information from within the notification, this notification-id MUST
allow the identification of the specific contents of notification as it
exits the publisher.";
} }
identity observation-domain-id { identity observation-domain-id {
base optional-notification-header; base optional-notification-header;
description description
"Header information identifying the software entity which created "Header information identifying the software entity which created
the notification (e.g., process id)."; the notification (e.g., process id).";
} }
identity notification-signature { identity notification-signature {
base optional-notification-header; base optional-notification-header;
description description
"Header information consisting of the information which backs up "Header information consisting of a signature which can be used to prove
the assertions made as to the validity of the information the authenticity that some asserter validates over the information
provided within the notification."; provided within the notification.";
} }
identity notification-integrity-evidence { identity notification-integrity-evidence {
base optional-notification-header; base optional-notification-header;
description description
"Header information consisting of the information which backs up "Header information consisting of the information which backs up
the assertions made as to the validity of the information the assertions made as to the validity of the information
provided within the notification."; provided within the notification.";
} }
skipping to change at page 14, line 30 skipping to change at page 14, line 25
* GROUPINGS * GROUPINGS
*/ */
grouping message-header { grouping message-header {
description description
"Header information included with a message."; "Header information included with a message.";
leaf message-time { leaf message-time {
type yang:date-and-time; type yang:date-and-time;
mandatory true; mandatory true;
description description
"time the message was generated prior to being sent to "Time the message was generated prior to being sent to
transport."; transport.";
} }
leaf message-id { leaf message-id {
type uint32; type uint32;
description description
"Id for a message going to a receiver from a message "Id for a message going to a receiver from a message
generator. The id will increment by one with each message sent generator. The id will increment by one with each message sent
from a particular message generator, allowing the message-id from a particular message generator, allowing the message-id
to be used as a sequence number."; to be used as a sequence number.";
} }
leaf message-generator-id { leaf message-generator-id {
type string; type string;
description description
"Software entity which created the message (e.g., linecard 1). "Software entity which created the message (e.g., linecard 1).
The combination of message-id and message-generator-id must be The combination of message-id and message-generator-id must be
unique until reset or a roll-over occurs."; unique until reset or a roll-over occurs.";
} }
leaf notification-count { leaf notification-count {
type uint16; type uint16;
description description
"Quantity of notification records in a bundled-message "Quantity of notifications in a bundled-message to a
specific receiver."; specific receiver.";
} }
} }
grouping notification-within-a-module {
description
"A location of a notification within a yang model.";
leaf yang-module {
type yang:yang-identifier;
description
"Name of the YANG module supported by the publisher.";
}
leaf yang-notification-name {
type notification-type;
description
"The name of a notification likely from a YANG module. Note
that this object should be in the notification contents, so a
debate is needed whether this is redundant.";
}
}
grouping notification-header { grouping notification-header {
description description
"Common informational objects which might help a receiver "Common informational objects which might help a receiver
interpret the meaning, details, or importance of a notification."; interpret the meaning, details, or importance of a notification.";
leaf notification-time { leaf notification-time {
type yang:date-and-time; type yang:date-and-time;
mandatory true; mandatory true;
description description
"Time the system recognized the occurrence of an event."; "Time the system recognized the occurrence of an event.";
} }
uses notification-within-a-module; leaf yang-module {
type yang:yang-identifier;
description
"Name of the YANG module supported by the publisher.";
}
leaf-list subscription-id { leaf-list subscription-id {
type uint32; type uint32;
description description
"Id of the subscription which led to the notification being "Id of the subscription which led to the notification being
generated."; generated.";
} }
leaf notification-id { leaf notification-id {
type uint32; type uint32;
description description
"Identifier for the notification record."; "Identifier for the notification record.";
skipping to change at page 16, line 4 skipping to change at page 15, line 34
leaf notification-id { leaf notification-id {
type uint32; type uint32;
description description
"Identifier for the notification record."; "Identifier for the notification record.";
} }
leaf observation-domain-id { leaf observation-domain-id {
type string; type string;
description description
"Software entity which created the notification record (e.g., "Software entity which created the notification record (e.g.,
process id)."; process id).";
} }
} }
grouping security-footer { grouping security-footer {
description description
"Reusable grouping for common objects which apply to the the "Reusable grouping for common objects which apply to the signing of
signing of notifications or messages."; notifications or messages.";
leaf signature-algorithm { leaf signature-algorithm {
type string; type string;
mandatory true; mandatory true;
description description
"The technology with which an originator signed of some "The technology with which an originator signed of some
delineated contents."; delineated contents.";
} }
leaf signature-value { leaf signature-value {
type string; type string;
mandatory true; mandatory true;
skipping to change at page 16, line 42 skipping to change at page 16, line 23
certificate, was performed with a TCG compliant TPM certificate, was performed with a TCG compliant TPM
environment. This evidence is never included in within any environment. This evidence is never included in within any
signature."; signature.";
reference reference
"TCG Infrastructure Workgroup, Subject Key Attestation Evidence "TCG Infrastructure Workgroup, Subject Key Attestation Evidence
Extension, Specification Version 1.0, Revision 7."; Extension, Specification Version 1.0, Revision 7.";
} }
} }
/* /*
* YANG-DATA messages for receivers * YANG encoded structures which can be sent to receivers
*/ */
rc:yang-data message { sx:structure message {
container message { container message {
presence presence
"Indicates attempt to communicate notifications to a receiver."; "Indicates attempt to communicate notifications to a receiver.";
description description
"Message to a receiver containing one or more notifications"; "Message to a receiver containing one or more notifications";
container message-header { container message-header {
description description
"Header info for messages."; "Header info for messages.";
uses message-header; uses message-header;
} }
list notifications { list notifications {
description description
"Set of notifications to a receiver."; "Set of notifications to a receiver.";
container notification-header { container notification-header {
description description
skipping to change at page 18, line 20 skipping to change at page 17, line 47
publisher."; publisher.";
} }
list yang-notification-specific-default { list yang-notification-specific-default {
key "yang-module yang-notification-name"; key "yang-module yang-notification-name";
description description
"For any included YANG notifications, this list provides "For any included YANG notifications, this list provides
additional optional headers which should be placed within the additional optional headers which should be placed within the
container notification-header if the receiver supports this container notification-header if the receiver supports this
specification. This list incrementally adds to any headers specification. This list incrementally adds to any headers
indicated within the leaf-list 'additional-headers'."; indicated within the leaf-list 'additional-headers'.";
uses notification-within-a-module; leaf yang-module {
type yang:yang-identifier;
description
"Name of the YANG module supported by the publisher.";
}
leaf yang-notification-name {
type notification-type;
description
"The name of a notification within a YANG module.";
}
leaf-list additional-notification-headers { leaf-list additional-notification-headers {
type optional-notification-header; type optional-notification-header;
description description
"The set of additional default headers which will be sent "The set of additional default headers which will be sent
for a specific YANG notification."; for a specific notification.";
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
8. Backwards Compatibility 8. Backwards Compatibility
With this specification, there is no change to YANG's 'notification' With this specification, there is no change to YANG's 'notification'
skipping to change at page 19, line 11 skipping to change at page 19, line 4
the purview of the Publisher. A receiver could slow delivery to the purview of the Publisher. A receiver could slow delivery to
existing subscriptions by creating new ones. (Which would result in existing subscriptions by creating new ones. (Which would result in
the publisher going into a bundling mode.) the publisher going into a bundling mode.)
10. Acknowledgments 10. Acknowledgments
For their valuable comments, discussions, and feedback, we wish to For their valuable comments, discussions, and feedback, we wish to
acknowledge Martin Bjorklund, Einar Nilsen-Nygaard, and Kent Watsen. acknowledge Martin Bjorklund, Einar Nilsen-Nygaard, and Kent Watsen.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.draft-ietf-netconf-subscribed-notifications] [I-D.draft-ietf-netconf-subscribed-notifications]
Voit, E., Clemm, A., Gonzalez Prieto, A., Tripathy, A., Voit, E., Clemm, A., Gonzalez Prieto, A., Tripathy, A.,
and E. Nilsen-Nygaard, "Custom Subscription to Event and E. Nilsen-Nygaard, "Custom Subscription to Event
Streams", draft-ietf-netconf-subscribed-notifications-16 Streams", draft-ietf-netconf-subscribed-notifications-16
(work in progress), August 2018. (work in progress), August 2019.
[I-D.draft-ietf-netmod-yang-data-ext]
Bierman, A., Bjorklund, M., and K. Watsen, "YANG Data
Structure Extensions", draft-ietf-netmod-yang-data-ext
(work in progress), July 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008,
<https://www.rfc-editor.org/info/rfc5277>. <https://www.rfc-editor.org/info/rfc5277>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References 11.2. Informative References
[I-D.draft-ietf-netconf-restconf-notif] [I-D.draft-ietf-netconf-restconf-notif]
Voit, Eric., Clemm, Alexander., Tripathy, A., Nilsen- Voit, Eric., Clemm, Alexander., Tripathy, A., Nilsen-
Nygaard, E., and Alberto. Gonzalez Prieto, "Restconf and Nygaard, E., and Alberto. Gonzalez Prieto, "Restconf and
HTTP transport for event notifications", June 2018, HTTP transport for event notifications", August 2019,
<https://datatracker.ietf.org/doc/ <https://datatracker.ietf.org/doc/
draft-ietf-netconf-restconf-notif/>. draft-ietf-netconf-restconf-notif/>.
[I-D.ietf-netconf-yang-push] [I-D.ietf-netconf-yang-push]
Clemm, Alexander., Voit, Eric., Gonzalez Prieto, Alberto., Clemm, Alexander., Voit, Eric., Gonzalez Prieto, Alberto.,
Tripathy, A., Nilsen-Nygaard, E., Bierman, A., and B. Tripathy, A., Nilsen-Nygaard, E., Bierman, A., and B.
Lengyel, "YANG Datastore Subscription", August 2018, Lengyel, "YANG Datastore Subscription", August 2019,
<https://datatracker.ietf.org/doc/ <https://datatracker.ietf.org/doc/
draft-ietf-netconf-yang-push/>. draft-ietf-netconf-yang-push/>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
Appendix A. Changes between revisions Appendix A. Changes between revisions
(To be removed by RFC editor prior to publication) (To be removed by RFC editor prior to publication)
v05 - v06
o With SN and YP getting RFC numbers, revisiting this document.
o Changed yang-data to draft-ietf-netmod-yang-data-ext's
'structure'.
o Removed the ability to reference structures other than YANG
notifications.
v04 - v05 v04 - v05
o Revision before expiration. Awaiting closure of SN and YP prior o Revision before expiration. Awaiting closure of SN and YP prior
to update. to update.
v03 - v04 v03 - v04
o Terminology tweaks. o Terminology tweaks.
o Revision before expiration. Awaiting closure of SN prior to o Revision before expiration. Awaiting closure of SN prior to
skipping to change at page 21, line 18 skipping to change at page 21, line 28
o Removed dscp and record-type as common headers. (Record type can o Removed dscp and record-type as common headers. (Record type can
be determined by the namespace of the record contents. Dscp is be determined by the namespace of the record contents. Dscp is
useful where applications need internal communications within a useful where applications need internal communications within a
Publisher, but it is unclear as to whether this use case need be Publisher, but it is unclear as to whether this use case need be
exposed to a receiver. exposed to a receiver.
Appendix B. Issues being worked Appendix B. Issues being worked
(To be removed by RFC editor prior to publication) (To be removed by RFC editor prior to publication)
Is this capability just for notifications, or is it for any yang-data
element too?
A complete JSON document is supposed to be sent as part of Media Type A complete JSON document is supposed to be sent as part of Media Type
"application/yang-data+json". As we are sending separate "application/yang-data+json". As we are sending separate
notifications after each other, we need to choose whether we start notifications after each other, we need to choose whether we start
with some extra encapsulation for the very first message pushed, or with some extra encapsulation for the very first message pushed, or
if we want a new Media Type for streaming updates. if we want a new Media Type for streaming updates.
Improved discovery mechanisms for NETCONF Improved discovery mechanisms for NETCONF
Should we defer support for HTTP2 configured subscriptions until this
draft is available? Without capabilities exchange, it might just be
easier to wait. In addition, JSON encoding still needs a
notification type which is not exising or represented in
referenceable in existing yang-models.
Need to ensure the proper references exist to a notification Need to ensure the proper references exist to a notification
definition driven by RFC-7950 which is acceptable to other eventual definition driven by RFC-7950 which is acceptable to other eventual
users of this specification. users of this specification.
We need to link to Andy Bierman's anydata extensibility draft for
informational purposes. This is under a WG adoption call.
Appendix C. Subscription Specific Headers Appendix C. Subscription Specific Headers
(To be removed by RFC editor prior to publication) (To be removed by RFC editor prior to publication)
This section discusses a future functional addition which could This section discusses a future functional addition which could
leverage this draft. It is included for informational purposes only. leverage this draft. It is included for informational purposes only.
A dynamic subscriber might want to mandate that certain headers be A dynamic subscriber might want to mandate that certain headers be
used for push updates from a publisher. Some examples of this used for push updates from a publisher. Some examples of this
include a subscriber requesting to: include a subscriber requesting to:
 End of changes. 68 change blocks. 
129 lines changed or deleted 118 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/