draft-ietf-netconf-notification-messages-07.txt   draft-ietf-netconf-notification-messages-08.txt 
NETCONF E. Voit NETCONF E. Voit
Internet-Draft Cisco Systems Internet-Draft T. Jenkins
Intended status: Standards Track H. Birkholz Intended status: Standards Track Cisco Systems
Expires: February 16, 2020 Fraunhofer SIT Expires: May 18, 2020 H. Birkholz
Fraunhofer SIT
A. Bierman A. Bierman
YumaWorks YumaWorks
A. Clemm A. Clemm
Futurewei Futurewei
T. Jenkins November 15, 2019
Cisco Systems
August 15, 2019
Notification Message Headers and Bundles Notification Message Headers and Bundles
draft-ietf-netconf-notification-messages-07 draft-ietf-netconf-notification-messages-08
Abstract Abstract
This document defines a new notification message format. Included This document defines a new notification message format. 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.
skipping to change at page 1, line 49 skipping to change at page 1, line 48
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 February 16, 2020. This Internet-Draft will expire on May 18, 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 35 skipping to change at page 2, line 35
4. Encapsulation of Header Objects in Messages . . . . . . . . . 4 4. Encapsulation of Header Objects in Messages . . . . . . . . . 4
4.1. One Notification per Message . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 18 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Changes between revisions . . . . . . . . . . . . . 20 Appendix A. Changes between revisions . . . . . . . . . . . . . 19
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 have been Mechanisms to support subscription to event notifications have been
defined in [I-D.draft-ietf-netconf-subscribed-notifications] and defined in [RFC8639] and [RFC8641]. Work on those documents has
[I-D.ietf-netconf-yang-push]. Work on those documents has shown that shown that notifications described in [RFC7950] section 7.16 could
notifications described in [RFC7950] section 7.16 could benefit from benefit from transport independent headers. With such headers,
transport independent headers. With such headers, communicating the communicating the following information to receiving applications can
following information to receiving applications can be done without be done without explicit linkage to an underlying transport protocol:
explicit linkage to an underlying transport protocol:
o the time the notification was generated o the time the notification was generated
o the time the notification was placed in a message and queued for o the time the notification was placed in a message and queued for
transport transport
o an identifier for the process generating the notification o an identifier for the process generating the notification
o signatures to verify authenticity o signatures to verify authenticity
skipping to change at page 3, line 39 skipping to change at page 3, line 37
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 [RFC7950] Section 4.2.10. The definition of notification is in [RFC7950] Section 4.2.10.
Publisher, receiver, subscription, and event occurrence time are Publisher, receiver, subscription, and event occurrence time are
defined in [I-D.draft-ietf-netconf-subscribed-notifications]. defined in [RFC8639].
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.
skipping to change at page 7, line 19 skipping to change at page 7, line 19
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
</notification-count> </notification-count>
</message-header> </message-header>
<notifications> <notifications>
<notification> <notification-header>
<notification-header> <notification-time>
<notification-time> 2017-02-14T00:00:02Z
2017-02-14T00:00:02Z </notification-time>
</notification-time> <subscription-id>
<subscription-id> 823472
823472 </subscription-id>
</subscription-id> <yang-module>
<yang-module> ietf-yang-push
ietf-yang-push </yang-module>
</yang-module> <yang-notification-name>
<yang-notification-name> push-change-update
push-change-update </yang-notification-name>
</yang-notification-name> </notification-header>
</notification-header> <notification-contents>
<notification-contents> <push-change-update xmlns=
<push-change-update xmlns= "urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
"urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0"> <datastore-changes-xml>
<datastore-changes-xml> <alpha xmlns="http://example.com/sample-data/1.0">
<alpha xmlns="http://example.com/sample-data/1.0"> <beta urn:ietf:params:xml:ns:netconf:base:1.0:
<beta urn:ietf:params:xml:ns:netconf:base:1.0: operation="delete"/>
operation="delete"/> </alpha>
</alpha> </datastore-changes-xml>
</datastore-changes-xml> </push-change-update>
</push-change-update> </notification-contents>
</notification-contents> <notification-header>
</notification> ...(notification header, contents, footer)...
<notification> </notification-footer>
...(record #2)...
</notification>
</notifications> </notifications>
</structure> </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
skipping to change at page 9, line 48 skipping to change at page 9, line 48
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. There is no guarantee that a capability exchange has taken the case. There is no guarantee that a capability exchange has taken
place before the messages are emitted. A solution for this in the place before the messages are emitted. A solution for this in the
case of HTTP based transport could be that a receiver would have to case of HTTP based transport could be that a receiver would have to
reply "ok" and also return the client capabilities as part a response reply "ok" and also return the client capabilities as part a response
to the initiation of the POST. to the initiation of the POST.
7. YANG Module 7. YANG Module
<CODE BEGINS> file "ietf-notification-messages@2019-08-16.yang" <CODE BEGINS> file "ietf-notification-messages@2019-10-10.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-yang-structure-ext { prefix sx; } import ietf-yang-structure-ext { prefix sx; }
organization "IETF"; organization "IETF";
skipping to change at page 10, line 34 skipping to change at page 10, line 34
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 "This module contains conceptual YANG specifications for
messages carrying notifications with well-known header objects."; messages carrying notifications with well-known header objects.";
revision 2019-08-16 { revision 2019-10-10 {
description description
"Initial version."; "Initial version.";
reference reference
"draft-ietf-netconf-notification-messages-07"; "draft-ietf-netconf-notification-messages-08";
} }
/* /*
* 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 16, line 27 skipping to change at page 16, line 27
"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 encoded structures which can be sent to receivers * YANG encoded structures which can be sent to receivers
*/ */
sx:structure message { sx:structure message {
container message { container message-header {
presence
"Indicates attempt to communicate notifications to a receiver.";
description description
"Message to a receiver containing one or more notifications"; "Header info for messages.";
container message-header { uses message-header;
}
list notifications {
description
"Set of notifications to a receiver.";
container notification-header {
description description
"Header info for messages."; "Header info for a notification.";
uses message-header; uses notification-header;
} }
list notifications { anydata notification-contents {
description description
"Set of notifications to a receiver."; "Encapsulates objects following YANG's notification-stmt
container notification-header { grammar of RFC-7950 section 14. Within are the notified
description objects the publisher actually generated in order to be
"Header info for a notification."; passed to a receiver after all filtering has completed.";
uses notification-header;
}
anydata notification-contents {
description
"Encapsulates objects following YANG's notification-stmt
grammar of RFC-7950 section 14. Within are the notified
objects the publisher actually generated in order to be
passed to a receiver after all filtering has completed.";
}
container notification-footer {
presence
"Indicates attempt to secure a notification.";
description
"Signature and evidence for messages.";
uses security-footer;
}
} }
container message-footer { container notification-footer {
presence presence
"Indicates attempt to secure the entire message."; "Indicates attempt to secure a notification.";
description description
"Signature and evidence for messages."; "Signature and evidence for messages.";
uses security-footer; uses security-footer;
} }
} }
container message-footer {
presence
"Indicates attempt to secure the entire message.";
description
"Signature and evidence for messages.";
uses security-footer;
}
} }
/* /*
* DATA-NODES * DATA-NODES
*/ */
container additional-default-headers { container additional-default-headers {
if-feature "publisher"; if-feature "publisher";
description description
"This container maintains a list of which additional notifications "This container maintains a list of which additional notifications
skipping to change at page 19, line 4 skipping to change at page 18, line 42
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
[I-D.draft-ietf-netconf-subscribed-notifications] 11.1. Normative References
Voit, E., Clemm, A., Gonzalez Prieto, A., Tripathy, A.,
and E. Nilsen-Nygaard, "Custom Subscription to Event
Streams", draft-ietf-netconf-subscribed-notifications-16
(work in progress), August 2019.
[I-D.draft-ietf-netmod-yang-data-ext] [I-D.draft-ietf-netmod-yang-data-ext]
Bierman, A., Bjorklund, M., and K. Watsen, "YANG Data Bierman, A., Bjorklund, M., and K. Watsen, "YANG Data
Structure Extensions", draft-ietf-netmod-yang-data-ext Structure Extensions", draft-ietf-netmod-yang-data-ext
(work in progress), July 2019. (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 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
E., and A. Tripathy, "Subscription to YANG Notifications",
[I-D.draft-ietf-netconf-restconf-notif] RFC 8639, DOI 10.17487/RFC8639, September 2019,
Voit, Eric., Clemm, Alexander., Tripathy, A., Nilsen- <https://www.rfc-editor.org/info/rfc8639>.
Nygaard, E., and Alberto. Gonzalez Prieto, "Restconf and
HTTP transport for event notifications", August 2019,
<https://datatracker.ietf.org/doc/
draft-ietf-netconf-restconf-notif/>.
[I-D.ietf-netconf-yang-push] 11.2. Informative References
Clemm, Alexander., Voit, Eric., Gonzalez Prieto, Alberto.,
Tripathy, A., Nilsen-Nygaard, E., Bierman, A., and B.
Lengyel, "YANG Datastore Subscription", August 2019,
<https://datatracker.ietf.org/doc/
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>.
[RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications
for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
September 2019, <https://www.rfc-editor.org/info/rfc8641>.
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)
v06 - v07 v06 - v08
o Updated author affiliation. o Removed redundant container from message
v05 - v06 o References and example updates
v05 - v06
o With SN and YP getting RFC numbers, revisiting this document. o With SN and YP getting RFC numbers, revisiting this document.
o Changed yang-data to draft-ietf-netmod-yang-data-ext's o Changed yang-data to draft-ietf-netmod-yang-data-ext's
'structure'. 'structure'.
o Removed the ability to reference structures other than YANG o Removed the ability to reference structures other than YANG
notifications. notifications.
v04 - v05 v04 - v05
skipping to change at page 22, line 19 skipping to change at page 21, line 47
o establish this subscription, but just if transport messages o establish this subscription, but just if transport messages
containing the pushed data will be encrypted, containing the pushed data will be encrypted,
o establish this subscription, but only if you can attest to the o establish this subscription, but only if you can attest to the
information being delivered in requested notification records, or information being delivered in requested notification records, or
o provide a sequence-id for all messages to this receiver (in order o provide a sequence-id for all messages to this receiver (in order
to check for loss). to check for loss).
Providing this type of functionality would necessitate a new revision Providing this type of functionality would necessitate a new revision
of the [I-D.draft-ietf-netconf-subscribed-notifications]'s RPCs and of the [RFC8639]'s RPCs and state change notifications. Subscription
state change notifications. Subscription specific header information specific header information would overwrite the default headers
would overwrite the default headers identified in this document. identified in this document.
Appendix D. Implications to Existing RFCs Appendix D. Implications to Existing RFCs
(To be removed by RFC editor prior to publication) (To be removed by RFC editor prior to publication)
YANG one-way exchanges currently use a non-extensible header and YANG one-way exchanges currently use a non-extensible header and
encoding defined in section 4 of RFC-5277. These RFCs MUST be encoding defined in section 4 of RFC-5277. These RFCs MUST be
updated to enable this draft. These RFCs SHOULD be updated to updated to enable this draft. These RFCs SHOULD be updated to
provide examples provide examples
skipping to change at page 23, line 4 skipping to change at page 22, line 32
Section 6.4 demands use of RFC-5277's netconf:notification:1.0, and Section 6.4 demands use of RFC-5277's netconf:notification:1.0, and
later in the section provides an example. later in the section provides an example.
Authors' Addresses Authors' Addresses
Eric Voit Eric Voit
Cisco Systems Cisco Systems
Email: evoit@cisco.com Email: evoit@cisco.com
Tim Jenkins
Cisco Systems
Email: timjenki@cisco.com
Henk Birkholz Henk Birkholz
Fraunhofer SIT Fraunhofer SIT
Email: henk.birkholz@sit.fraunhofer.de Email: henk.birkholz@sit.fraunhofer.de
Andy Bierman Andy Bierman
YumaWorks YumaWorks
Email: andy@yumaworks.com Email: andy@yumaworks.com
Alexander Clemm Alexander Clemm
Futurewei Futurewei
Email: ludwig@clemm.org Email: ludwig@clemm.org
Tim Jenkins
Cisco Systems
Email: timjenki@cisco.com
 End of changes. 34 change blocks. 
107 lines changed or deleted 94 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/