draft-ietf-netconf-notification-messages-01.txt   draft-ietf-netconf-notification-messages-02.txt 
NETCONF E. Voit NETCONF E. Voit
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track A. Bierman Intended status: Standards Track A. Bierman
Expires: April 2, 2018 YumaWorks Expires: April 6, 2018 YumaWorks
A. Clemm A. Clemm
Huawei Huawei
T. Jenkins T. Jenkins
Cisco Systems Cisco Systems
September 29, 2017 October 03, 2017
Notification Message Headers and Bundles Notification Message Headers and Bundles
draft-ietf-netconf-notification-messages-01 draft-ietf-netconf-notification-messages-02
Abstract Abstract
This document defines a new notification message format, using yang- This document defines a new notification message format, using yang-
data. Included are: data. Included 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 47 skipping to change at page 1, line 47
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 April 2, 2018. This Internet-Draft will expire on April 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 28 skipping to change at page 2, line 28
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 . . . . . . . . . . . . . . 5
4.2. Many Notifications per Message . . . . . . . . . . . . . 6 4.2. Many Notifications per Message . . . . . . . . . . . . . 6
4.3. Notification Type in Payload . . . . . . . . . . . . . . 9 4.3. Notification Type in Payload . . . . . . . . . . . . . . 8
5. Configuration of Headers . . . . . . . . . . . . . . . . . . 9 5. Configuration of Headers . . . . . . . . . . . . . . . . . . 8
6. Discovering Receiver Support . . . . . . . . . . . . . . . . 10 6. Discovering Receiver Support . . . . . . . . . . . . . . . . 9
7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 17 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Changes between revisions . . . . . . . . . . . . . 19 Appendix A. Changes between revisions . . . . . . . . . . . . . 19
Appendix B. Issues being worked . . . . . . . . . . . . . . . . 19 Appendix B. Issues being worked . . . . . . . . . . . . . . . . 20
Appendix C. Subscription Specific Headers . . . . . . . . . . . 20 Appendix C. Subscription Specific Headers . . . . . . . . . . . 20
Appendix D. Implications to Existing RFCs . . . . . . . . . . . 20 Appendix D. Implications to Existing RFCs . . . . . . . . . . . 21
D.1. Implications to RFC-7950 . . . . . . . . . . . . . . . . 20 D.1. Implications to RFC-7950 . . . . . . . . . . . . . . . . 21
D.2. Implications to RFC-8040 . . . . . . . . . . . . . . . . 21 D.2. Implications to RFC-8040 . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
Mechanisms to support subscription to event notifications and yang Mechanisms to support subscription to event notifications and yang
datastore push are being defined in [subscribe] and [yang-push]. datastore push are being defined in [subscribe] and [yang-push].
Work on those documents has shown that notifications described in Work on those documents has shown that notifications described in
[RFC7950] section 7.16 could benefit from transport independent [RFC7950] section 7.16 could benefit from transport independent
headers. Communicating the following information to receiving headers. Communicating the following information to receiving
skipping to change at page 3, line 50 skipping to change at page 3, line 50
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 time an event, datastore update, or other
item is recognized and recorded within the publisher. item is recognized and recorded within the publisher.
o notification-id: Identifies the name of the notification, per the o notification-id: Identifies the name of the notification, per the
YANG notification statement. May also provide the name of a yang- YANG notification statement. May also provide the name of a yang-
data statement (wheterh this is in scope is tbd). 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 5, line 21 skipping to change at page 5, line 21
Below are contents of a message when there is only one notification Below are contents of a message when there is only one notification
in an encapsulated and encoded message: in an encapsulated and encoded message:
yang-data message yang-data message
+-- message-header +-- message-header
| +-- notification-time yang:date-and-time | +-- notification-time yang:date-and-time
| +-- subscription-id* uint32 | +-- subscription-id* uint32
| +-- notification-id? uint32 | +-- notification-id? uint32
| +-- observation-domain-id? string | +-- observation-domain-id? string
| +-- module? yang-identifier
| +-- notification-type? notification
| +-- message-id? uint32 | +-- message-id? uint32
| +-- message-time? yang:date-and-time | +-- message-time? yang:date-and-time
| +-- previous-message-id? uint32 | +-- previous-message-id? uint32
| +-- message-generator-id? string | +-- message-generator-id? string
| +-- signature? string | +-- signature? string
+-- receiver-record-contents? +-- receiver-record-contents?
An actual instance of such a message when encoded in XML might look An actual instance of such a message when encoded in XML might look
like: like:
<yang-data message <yang-data 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>
<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>
<module>
ietf-yang-push
</module>
<notification-type>
push-change-update
</notification-type>
<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>
<previous-message-id> <previous-message-id>
567 567
</previous-message-id> </previous-message-id>
<signature> <signature>
skipping to change at page 7, line 21 skipping to change at page 7, line 27
| +-- message-id? uint32 | +-- message-id? uint32
| +-- previous-message-id? uint32 | +-- previous-message-id? uint32
| +-- message-generator-id? string | +-- message-generator-id? string
| +-- signature? string | +-- signature? string
| +-- notification-count? uint16 | +-- notification-count? uint16
+-- notifications* +-- notifications*
+-- notification-header +-- notification-header
| +-- notification-time yang:date-and-time | +-- notification-time yang:date-and-time
| +-- subscription-id* uint32 | +-- subscription-id* uint32
| +-- notification-id? uint32 | +-- notification-id? uint32
| +-- module? yang-identifier
| +-- notification-type? notification
| +-- observation-domain-id? string | +-- observation-domain-id? string
+-- receiver-record-contents? +-- receiver-record-contents?
An actual instance of a bundled notification might look like: An actual instance of a bundled notification might look like:
<yang-data bundled-message <yang-data 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">
<bundled-message-header> <bundled-message-header>
<message-time> <message-time>
2017-02-14T00:00:05Z 2017-02-14T00:00:05Z
skipping to change at page 8, line 33 skipping to change at page 8, line 16
</bundled-message-header> </bundled-message-header>
<notifications> <notifications>
<notification> <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>
<module>
ietf-yang-push
</module>
<notification-type>
push-change-update
</notification-type>
</notification-header> </notification-header>
<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>
skipping to change at page 9, line 42 skipping to change at page 9, line 26
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. these are identified to a publisher is out-of-scope.
The set of headers used for any particular message is the superset of The set of headers used for any particular message is the superset of
headers for the items listed above. headers for the items listed above.
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* common-header +--rw additional-headers* common-header
+--rw notification-specific-default* [module notification] +--rw notification-specific-default* [module notification]
+--rw module yang:yang-identifier +--rw module yang:yang-identifier
+--rw notification string +--rw notification notification
+--rw per-notification-headers* common-header +--rw per-notification-headers* common-header
Configuration Model structure Configuration Model structure
Of note in this tree is the optional feature of 'publisher'. This Of note in this tree is the optional feature of 'publisher'. This
feature indicates an ability to send notifications. A publisher feature indicates an ability to send notifications. A publisher
supporting this specification MUST also be able to parse any messages supporting this specification MUST also be able to parse any messages
received as defined in this document. received as defined in this document.
6. Discovering Receiver Support 6. Discovering Receiver Support
skipping to change at page 11, line 38 skipping to change at page 11, line 23
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 yang-data
messages carrying notifications with well known header objects."; messages carrying notifications with well known header objects.";
revision 2017-09-28 { revision 2017-10-03 {
description description
"Initial version."; "Initial version.";
reference reference
"draft-ietf-netconf-notification-messages-01"; "draft-ietf-netconf-notification-messages-02";
} }
/* /*
* 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 12, line 19 skipping to change at page 12, line 4
* 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 notification-time { identity notification-time {
base common-header; base common-header;
description description
"Header information consisting of the time an originating process "Header information consisting of the time an originating process
created the notification or yang-data."; created the notification.";
} }
identity notification-id { identity notification-id {
base common-header; base common-header;
description description
"Header information consisting of an identifier for the "Header information consisting of an identifier for an instance
notification or yang-data record. "; of a notification egressing a publisher. ";
} }
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 or yang-data being subscription associated with the notification being
encapsulated."; encapsulated.";
} }
identity observation-domain-id { identity observation-domain-id {
base common-header; base common-header;
description description
"Header information identifying the software entity which created "Header information identifying the software entity which created
the notification or yang-data (e.g., process id)."; the notification (e.g., process id).";
} }
identity message-id { identity message-id {
base common-header; base common-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-time { identity message-time {
skipping to change at page 14, line 11 skipping to change at page 13, line 43
typedef common-header { typedef common-header {
type identityref { type identityref {
base common-header; base common-header;
} }
description description
"Type of header object which may be included somewhere within a "Type of header object which may be included somewhere within a
message."; message.";
} }
typedef notification-type {
type string {
pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*';
}
description
"The name of a notification within a YANG module.";
reference
"RFC-7950 Section 7.16";
}
/* /*
* GROUPINGS * GROUPINGS
*/ */
grouping notification-and-module {
description
"A location of a notification within a yang model.";
leaf module {
type yang:yang-identifier;
description
"Name of the YANG module supported by the publisher.";
}
leaf notification {
type notification-type;
description
"The name of a notification within a YANG module.";
}
}
grouping message-header { grouping message-header {
description description
"Header information included with a message."; "Header information included with a message.";
leaf message-id { leaf message-id {
type uint32; type uint32;
description description
"Unique id for a message going to a receiver."; "Unique id for a message going to a receiver.";
} }
leaf message-time { leaf message-time {
type yang:date-and-time; type yang:date-and-time;
skipping to change at page 15, line 28 skipping to change at page 15, line 36
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).";
} }
uses notification-and-module;
} }
/* /*
* YANG-DATA messages for receivers * YANG-DATA messages for receivers
*/ */
/* Message to a receiver containing one notification.*/
rc:yang-data message { rc:yang-data message {
container message-header { container message {
description presence
"delineates header info from content for easy parsing."; "Indicates attempt to communicate notifications to a receiver.";
uses notification-header;
uses message-header;
}
anydata notification-contents {
description description
"Non-header info of what actually got sent to receiver. This "Message to a receiver containing one notification";
includes after any content based security filtering. Need to container message-header {
determine if/how it is viable not to include tag encapsulation description
for this object."; "delineates header info from content for easy parsing.";
uses notification-header;
uses message-header;
}
anydata notification-contents {
description
"Encapsultates 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.";
}
} }
} }
/* Message to a receiver containing many bundled notifications.*/
rc:yang-data bundled-message { rc:yang-data bundled-message {
container bundled-message-header { container bundled-message {
presence
"Indicates attempt to communicate notifications to a receiver.";
description
"Message to a receiver containing many bundled notifications";
container bundled-message-header {
description description
"Header info for messages."; "Header info for messages.";
uses message-header { uses message-header {
refine message-time { refine message-time {
mandatory true; mandatory true;
} }
} }
leaf notification-count { leaf notification-count {
type uint16; type uint16;
description description
"Quantity of notification records in a bundled-message "Quantity of notification records in a bundled-message
specific receiver."; specific receiver.";
} }
}
list notifications {
description
"Set of notifications to a receiver.";
container notification-header {
description
"Header info for each bundled notification.";
uses notification-header;
} }
anydata notification-contents { list notifications {
description description
"Non-header info of what actually got sent to receiver. This "Set of notifications to a receiver.";
includes after any content based security filtering. Need to container notification-header {
determine if/how it is viable not to include tag encapsulation description
for this object."; "Header info for each bundled notification.";
uses notification-header;
}
anydata notification-contents {
description
"Encapsultates 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.";
}
} }
} }
} }
/* /*
* DATA-NODES * DATA-NODES
*/ */
container additional-default-headers { container additional-default-headers {
if-feature "publisher"; if-feature "publisher";
skipping to change at page 17, line 13 skipping to change at page 17, line 33
type common-header; type common-header;
description description
"This list contains the additional default headers which are to "This list contains the additional default headers which are to
be applied to each message from this publisher."; be applied to each message from this publisher.";
} }
list notification-specific-default { list notification-specific-default {
key "module notification"; key "module notification";
description description
"For any included notification, this list provides additional "For any included notification, this list provides additional
common headers."; common headers.";
leaf module { uses notification-and-module;
type yang:yang-identifier;
description
"Name of the module containing a notification.";
}
leaf notification {
type string {
pattern 'notification $|yang-data $';
}
description
"The name of the notification or yang-data being sent.";
}
leaf-list per-notification-headers { leaf-list per-notification-headers {
type common-header; type common-header;
description description
"The set of additional default headers for a specific "The set of additional default headers for a specific
notification."; notification.";
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
skipping to change at page 18, line 13 skipping to change at page 18, line 20
resources based on this reason. resources based on this reason.
Decisions on whether to bundle or not to a receiver are fully under Decisions on whether to bundle or not to a receiver are fully under
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 and Kent Watsen. acknowledge Martin Bjorklund, Einar Nilsen-Nygaard, and Kent Watsen.
11. References 11. References
11.1. Normative References 11.1. Normative References
[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>.
skipping to change at page 19, line 24 skipping to change at page 19, line 36
Clemm, A., Voit, E., Gonzalez Prieto, A., Prasad Tripathy, Clemm, A., Voit, E., Gonzalez Prieto, A., Prasad Tripathy,
A., and E. Nilsen-Nygaard, "Subscribing to YANG datastore A., and E. Nilsen-Nygaard, "Subscribing to YANG datastore
push updates", April 2017, push updates", April 2017,
<https://datatracker.ietf.org/doc/ <https://datatracker.ietf.org/doc/
draft-ietf-netconf-yang-push/>. draft-ietf-netconf-yang-push/>.
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)
v01 - v02
o Fixed the yang-data encapsulation container issue
o Updated object definitions to point to RFC-7950 definitions
o Added headers for module and notification-type.
v00 - v01 v00 - v01
o Alternative to 5277 one-way notification added o Alternative to 5277 one-way notification added
o Storage of default headers by notification type o Storage of default headers by notification type
o Backwards compatibility o Backwards compatibility
o Capability discovery o Capability discovery
o Move to yang-data o Move to yang-data
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
skipping to change at page 19, line 49 skipping to change at page 20, line 19
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 Is this capability just for notifications, or is it for any yang-data
element too? element too?
There is redundancy with module and notification in the headers,
along with the notification name and the namespace as the first
element of the pushed content. Do we remove one of them?
A complete JSON document is supposed to be sent as part of Media Type
"application/yang-data+json". As we are sending separate
notifications after eachother, we need to choose whether we start
with some extra encapsulation for the very first message pushed, or
if we want a new Media Type for streaming updates.
Improved discovery mechanisms for NETCONF Improved discovery mechanisms for NETCONF
Do we want to have additional headers for a specific notification? Do we want to have additional headers for a specific notification?
Right now this is included, but it could be excluded. Right now this is included, but it could be excluded.
Should we defer support for HTTP2 configured subscriptions until this Should we defer support for HTTP2 configured subscriptions until this
draft is available? Without capabilities exchange, it might just be draft is available? Without capabilities exchange, it might just be
easier to wait. easier to wait. In addition, JSON encoding still needs a
notification type which is not exising or represented in
referenceable in existing yang-models.
Encoding of notification-contents so that individual notification Need to ensure the proper references exist to a notification
framing isn't needed. definition driven by RFC-7950 which is acceptable to other eventual
users of this specification.
We need to link to Andy Bierman's anydata extensibility draft. We need to link to Andy Bierman's anydata extensibility draft.
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.
 End of changes. 41 change blocks. 
69 lines changed or deleted 131 lines changed or added

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