idnits 2.17.1 draft-ietf-netconf-notification-messages-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 03, 2017) is 2397 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF E. Voit 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track A. Bierman 5 Expires: April 6, 2018 YumaWorks 6 A. Clemm 7 Huawei 8 T. Jenkins 9 Cisco Systems 10 October 03, 2017 12 Notification Message Headers and Bundles 13 draft-ietf-netconf-notification-messages-02 15 Abstract 17 This document defines a new notification message format, using yang- 18 data. Included are: 20 o a new notification mechanism and encoding to replace the one way 21 operation of RFC-5277 23 o a set of common, transport agnostic message header objects. 25 o how to bundle multiple event records into a single notification 26 message. 28 o how to ensure these new capabilities are only used with capable 29 receivers. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 6, 2018. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Header Objects . . . . . . . . . . . . . . . . . . . . . . . 3 68 4. Encapsulation of Header Objects in Messages . . . . . . . . . 4 69 4.1. One Notification per Message . . . . . . . . . . . . . . 5 70 4.2. Many Notifications per Message . . . . . . . . . . . . . 6 71 4.3. Notification Type in Payload . . . . . . . . . . . . . . 8 72 5. Configuration of Headers . . . . . . . . . . . . . . . . . . 8 73 6. Discovering Receiver Support . . . . . . . . . . . . . . . . 9 74 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 17 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 77 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 80 11.2. Informative References . . . . . . . . . . . . . . . . . 18 81 Appendix A. Changes between revisions . . . . . . . . . . . . . 19 82 Appendix B. Issues being worked . . . . . . . . . . . . . . . . 20 83 Appendix C. Subscription Specific Headers . . . . . . . . . . . 20 84 Appendix D. Implications to Existing RFCs . . . . . . . . . . . 21 85 D.1. Implications to RFC-7950 . . . . . . . . . . . . . . . . 21 86 D.2. Implications to RFC-8040 . . . . . . . . . . . . . . . . 21 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 89 1. Introduction 91 Mechanisms to support subscription to event notifications and yang 92 datastore push are being defined in [subscribe] and [yang-push]. 93 Work on those documents has shown that notifications described in 94 [RFC7950] section 7.16 could benefit from transport independent 95 headers. Communicating the following information to receiving 96 applications can be done without explicit linkage to an underlying 97 transport protocol: 99 o the time information was generated 101 o the time the information was sent 103 o a signature to verify authenticity 105 o the process generating the information 107 o an originating request correlation 109 o an ability to bundle information records into one a message 111 o the ability to check for message loss/reordering 113 The document describes information elements needed for the functions 114 above. It also provides YANG structures for sending messages 115 containing one or more events and/or update records to a receiver. 117 2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this document are to be interpreted as described in BCP 122 14 [RFC2119] [RFC8174] when, and only when, they appear in all 123 capitals, as shown here. 125 The definition of notification is in RFC 7950 [RFC7950]. Publisher, 126 receiver, and subscription are defined in [subscribe]. 128 3. Header Objects 130 There are a number of transport independent headers which should have 131 common definition. These include: 133 o subscription-id: provides a reference into the reason the 134 publisher believed the receiver wishes to be notified of this 135 specific information. 137 o notification-time: the time an event, datastore update, or other 138 item is recognized and recorded within the publisher. 140 o notification-id: Identifies the name of the notification, per the 141 YANG notification statement. May also provide the name of a yang- 142 data statement (whether transporting other types of messages is in 143 scope is tbd). 145 o observation-domain-id: identifies the publisher process which 146 discovered and recorded the event notification. (note: look to 147 reuse the domains set up with IPFIX.) 149 o message-time: the time the message was packaged sent to the 150 transport layer for delivery to the receiver. 152 o signature: allows an application to sign a message so that a 153 receiver can verify the authenticity of the message. 155 o message-id: for a specific message generator, this identifies a 156 message which includes one or more event records. 158 o previous-message-id: the message-id of the message preceding the 159 current one intended for the same receiver. When used in 160 conjunction with the current message-id, this allows loss/ 161 duplication across previous messages to be discovered. If there 162 was no previous message from a message generator, the reserved id 163 "0" must be sent. 165 o message-generator-id: identifier for the process which created the 166 message. This allows disambiguation of an information source, 167 such as the identification of different line cards sending the 168 messages. Used in conjunction with previous-message-id, this can 169 help find drops and duplications when messages are coming from 170 multiple sources on a device. If there is a message-generator-id 171 in the header, then the previous-message-id MUST be the message-id 172 from the last time that message-generator-id was sent. 174 4. Encapsulation of Header Objects in Messages 176 A specific set of well-known objects are of potential use to 177 networking layers prior being interpreted by some receiving 178 application layer process. By exposing this object information as 179 part of a header, and by using standardized object names, it becomes 180 possible for this object information to be leveraged in transit. 182 The objects defined in the previous section are these well-known 183 header objects. These objects are identified within a dedicated 184 header subtree which leads off a particular transportable message. 185 This allows header objects to be easily be decoupled, stripped, and 186 processed separately. 188 There are two types of transportable messages: one format is used 189 when there is one notification being encapsulated, and another format 190 used when there are many notifications being bundled into one 191 message. 193 A receiver which supporting this document MUST be able to handle 194 receipt of either type of message from an publisher. It is possible 195 that changes between message types can occur without any prior 196 indication. 198 4.1. One Notification per Message 200 Below are contents of a message when there is only one notification 201 in an encapsulated and encoded message: 203 yang-data message 204 +-- message-header 205 | +-- notification-time yang:date-and-time 206 | +-- subscription-id* uint32 207 | +-- notification-id? uint32 208 | +-- observation-domain-id? string 209 | +-- module? yang-identifier 210 | +-- notification-type? notification 211 | +-- message-id? uint32 212 | +-- message-time? yang:date-and-time 213 | +-- previous-message-id? uint32 214 | +-- message-generator-id? string 215 | +-- signature? string 216 +-- receiver-record-contents? 218 An actual instance of such a message when encoded in XML might look 219 like: 221 223 224 225 2017-02-14T00:00:02Z 226 227 228 823472 229 230 231 ietf-yang-push 232 233 234 push-change-update 235 236 237 2017-02-14T00:00:05Z 238 239 240 456 241 242 243 567 244 245 246 lKIo8s03fd23..... 247 248 249 251 252 253 255 256 257 258 260 4.2. Many Notifications per Message 262 In many implementations, it may be inefficient to transport every 263 notification independently. Instead, scale and processing speed can 264 be improved by placing multiple notifications into one transportable 265 bundle. 267 When this is done, one additional header field becomes valuable. 268 This is the "notification-count" which would tally the quantity of 269 records which make up the contents of the bundle. It is true that 270 the record count can be derived, but early access to this information 271 could change receiver processing. 273 The format of a bundle would look as below. When compared to the 274 unbundled notification, note that the headers have been split so that 275 one set of headers associated with the notification occur once at the 276 beginning of the message, and additional record specific headers 277 which occur before individual records. 279 yang-data bundled-message 280 +-- bundled-message-header 281 | +-- message-time yang:date-and-time 282 | +-- message-id? uint32 283 | +-- previous-message-id? uint32 284 | +-- message-generator-id? string 285 | +-- signature? string 286 | +-- notification-count? uint16 287 +-- notifications* 288 +-- notification-header 289 | +-- notification-time yang:date-and-time 290 | +-- subscription-id* uint32 291 | +-- notification-id? uint32 292 | +-- module? yang-identifier 293 | +-- notification-type? notification 294 | +-- observation-domain-id? string 295 +-- receiver-record-contents? 297 An actual instance of a bundled notification might look like: 299 301 302 303 2017-02-14T00:00:05Z 304 305 306 456 307 308 309 567 310 311 312 lKIo8s03fd23... 313 314 315 2 317 318 319 320 321 322 323 2017-02-14T00:00:02Z 324 325 326 823472 327 328 329 ietf-yang-push 330 331 332 push-change-update 333 334 335 337 338 339 341 342 343 344 345 346 ...(record #2)... 347 348 349 351 4.3. Notification Type in Payload 353 The type of notification transported within a record could be a 354 header. However the notification name and namespace is the first 355 element in the receiver record contents payload. As this can be 356 determined by the YANG module containing the notification-stmt as 357 represented within the first part of the encapsulated notification 358 message, this information need not replicated within a header. 360 5. Configuration of Headers 362 A publisher MUST select the set of headers to use for a particular 363 message. The two mandatory headers which MUST always be applied to 364 every message are 'message-time' and 'subscription-id' 365 Beyond these two mandatory headers, the following are additional 366 sources which can add common headers to a message. 368 1. Publisher wide default headers for all notifications. These are 369 included if a common header is inserted into 'additional-headers' 370 shown in the figure below. 372 2. More notification specific headers may also be desired. If new 373 headers are needed for a specific notification in the YANG model, 374 this can be populated through 'per-notification-headers'. 376 3. An application process may also identify common headers to use 377 when transporting notifications for a specific subscription. How 378 these are identified to a publisher is out-of-scope. 380 The set of headers used for any particular message is the superset of 381 headers for the items listed above. 383 The YANG tree showing elements of configuration is depicted in the 384 following figure. 386 module: ietf-notification-messages 387 +--rw additional-default-headers {publisher}? 388 +--rw additional-headers* common-header 389 +--rw notification-specific-default* [module notification] 390 +--rw module yang:yang-identifier 391 +--rw notification notification 392 +--rw per-notification-headers* common-header 394 Configuration Model structure 396 Of note in this tree is the optional feature of 'publisher'. This 397 feature indicates an ability to send notifications. A publisher 398 supporting this specification MUST also be able to parse any messages 399 received as defined in this document. 401 6. Discovering Receiver Support 403 We need capability exchange from the receiver to the publisher at 404 transport session initiation to indicate support for this 405 specification. 407 For all types of transport connections, if the receiver indicates 408 support for this specification, then it MAY be used. In addition, 409 [RFC5277] one-way notifications MUST NOT be used if the receiver 410 indicates support for this specification to a publisher which also 411 supports it. 413 Where NETCONF transport is used, advertising this specification's 414 namespace during an earlier client capabilities discovery phase MAY 415 be used to indicate support for this specification: 417 418 419 420 urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0 421 422 423 4 424 426 NOTE: It is understood that even though it is allowed in [RFC6241] 427 section 8.1, robust NETCONF client driven capabilities exchange is 428 not something which is common in implementation. Therefore reviewers 429 are asked to submit alternative proposals to the mailing list. 431 For RESTCONF, a mechanism for capability discovery is TBD. Proposals 432 are also welcome here. 434 The mechanism described above assumes that a capability discovery 435 phase happens before a subscription is started. This is not always 436 the case. As an example, consider HTTP2 configured subscriptions 437 from section 3.1.3 of [http-push], there is no guarantee that a 438 capability exchange has taken place before the updates are pushed. A 439 solution for this could be that a receiver would reply "ok" and reply 440 with the client capabilities as part of the POST. (Or just use a 441 different HTTP status code like 202 instead of 200 'ok'). As such a 442 requirement creates a new dependency for [http-push] upon this 443 specification, more discussion is required to decide if this is a 444 viable solution. 446 7. YANG Module 448 file "ietf-notification-messages.yang" 449 module ietf-notification-messages { 450 yang-version 1.1; 451 namespace 452 "urn:ietf:params:xml:ns:yang:ietf-notification-messages"; 453 prefix nm; 455 import ietf-yang-types { prefix yang; } 456 import ietf-restconf { prefix rc; } 458 organization "IETF"; 459 contact 460 "WG Web: 461 WG List: 463 Editor: Eric Voit 464 466 Editor: Alexander Clemm 467 469 Editor: Andy Bierman 470 472 Editor: Tim Jenkins 473 "; 475 description 476 "This module contains conceptual YANG specifications for yang-data 477 messages carrying notifications with well known header objects."; 479 revision 2017-10-03 { 480 description 481 "Initial version."; 483 reference 484 "draft-ietf-netconf-notification-messages-02"; 485 } 487 /* 488 * FEATURES 489 */ 491 feature publisher { 492 description 493 "This feature indicates that support for both publisher and 494 receiver of messages complying to the specification."; 495 } 497 /* 498 * IDENTITIES 499 */ 501 /* Identities for common headers */ 503 identity common-header { 504 description 505 "A well known header which can be included somewhere within a 506 message."; 507 } 508 identity notification-time { 509 base common-header; 510 description 511 "Header information consisting of the time an originating process 512 created the notification."; 513 } 515 identity notification-id { 516 base common-header; 517 description 518 "Header information consisting of an identifier for an instance 519 of a notification egressing a publisher. "; 520 } 522 identity subscription-id { 523 base common-header; 524 description 525 "Header information consisting of the identifier of the 526 subscription associated with the notification being 527 encapsulated."; 528 } 530 identity observation-domain-id { 531 base common-header; 532 description 533 "Header information identifying the software entity which created 534 the notification (e.g., process id)."; 535 } 537 identity message-id { 538 base common-header; 539 description 540 "Header information that identifies a message to a specific 541 receiver"; 542 } 544 identity message-time { 545 base common-header; 546 description 547 "Header information consisting of time the message headers were 548 placed generated prior to being sent to transport"; 549 } 551 identity previous-message-id { 552 base common-header; 553 description 554 "Header information consisting of a message id previously sent by 555 the publisher to a specific receiver (allows detection of 556 loss/duplication)."; 557 } 559 identity message-generator-id { 560 base common-header; 561 description 562 "Header information consisting of an identifier for a software 563 entity which created the message (e.g., linecard 1)."; 564 } 566 identity signature { 567 base common-header; 568 description 569 "Header information consisting of a signature on the contents of 570 a message. This can be useful for originating applications to 571 verify record contents even when shipping over unsecure 572 transport."; 573 } 575 identity notification-count { 576 base common-header; 577 description 578 "Header information consisting of the quantity of notifications in 579 a bundled-message for a specific receiver."; 580 } 582 /* 583 * TYPEDEFs 584 */ 586 typedef common-header { 587 type identityref { 588 base common-header; 589 } 590 description 591 "Type of header object which may be included somewhere within a 592 message."; 593 } 595 typedef notification-type { 596 type string { 597 pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*'; 598 } 599 description 600 "The name of a notification within a YANG module."; 601 reference 602 "RFC-7950 Section 7.16"; 603 } 604 /* 605 * GROUPINGS 606 */ 608 grouping notification-and-module { 609 description 610 "A location of a notification within a yang model."; 611 leaf module { 612 type yang:yang-identifier; 613 description 614 "Name of the YANG module supported by the publisher."; 615 } 616 leaf notification { 617 type notification-type; 618 description 619 "The name of a notification within a YANG module."; 620 } 621 } 623 grouping message-header { 624 description 625 "Header information included with a message."; 626 leaf message-id { 627 type uint32; 628 description 629 "Unique id for a message going to a receiver."; 630 } 631 leaf message-time { 632 type yang:date-and-time; 633 description 634 "time the message was generated prior to being sent to 635 transport."; 636 } 637 leaf previous-message-id { 638 type uint32; 639 description 640 "message id previously sent by publisher to a specific 641 receiver (allows detection of loss/duplication)."; 642 } 643 leaf message-generator-id { 644 type string; 645 description 646 "Software entity which created the message (e.g., linecard 1)."; 647 } 648 leaf signature { 649 type string; 650 description 651 "Any originator signing of the contents of a message. This can 652 be useful for originating applications to verify record contents 653 even when shipping over unsecure transport."; 654 } 655 } 657 grouping notification-header { 658 description 659 "Common informational objects which might help a receiver 660 interpret the meaning, details, or importance of a notification."; 661 leaf notification-time { 662 type yang:date-and-time; 663 mandatory true; 664 description 665 "Time the system recognized the occurrence of an event."; 666 } 667 leaf-list subscription-id { 668 type uint32; 669 description 670 "Id of the subscription which led to the notification being 671 generated."; 672 } 673 leaf notification-id { 674 type uint32; 675 description 676 "Identifier for the notification record."; 677 } 678 leaf observation-domain-id { 679 type string; 680 description 681 "Software entity which created the notification record (e.g., 682 process id)."; 683 } 684 uses notification-and-module; 685 } 687 /* 688 * YANG-DATA messages for receivers 689 */ 691 rc:yang-data message { 692 container message { 693 presence 694 "Indicates attempt to communicate notifications to a receiver."; 695 description 696 "Message to a receiver containing one notification"; 697 container message-header { 698 description 699 "delineates header info from content for easy parsing."; 701 uses notification-header; 702 uses message-header; 703 } 704 anydata notification-contents { 705 description 706 "Encapsultates objects following YANG's notification-stmt 707 grammar of RFC-7950 section 14. Within are the notified 708 objects the publisher actually generated in order to be 709 passed to a receiver after all filtering has completed."; 710 } 711 } 712 } 714 rc:yang-data bundled-message { 715 container bundled-message { 716 presence 717 "Indicates attempt to communicate notifications to a receiver."; 718 description 719 "Message to a receiver containing many bundled notifications"; 720 container bundled-message-header { 721 description 722 "Header info for messages."; 723 uses message-header { 724 refine message-time { 725 mandatory true; 726 } 727 } 728 leaf notification-count { 729 type uint16; 730 description 731 "Quantity of notification records in a bundled-message 732 specific receiver."; 733 } 734 } 735 list notifications { 736 description 737 "Set of notifications to a receiver."; 738 container notification-header { 739 description 740 "Header info for each bundled notification."; 741 uses notification-header; 742 } 743 anydata notification-contents { 744 description 745 "Encapsultates objects following YANG's notification-stmt 746 grammar of RFC-7950 section 14. Within are the notified 747 objects the publisher actually generated in order to be 748 passed to a receiver after all filtering has completed."; 750 } 751 } 752 } 753 } 755 /* 756 * DATA-NODES 757 */ 759 container additional-default-headers { 760 if-feature "publisher"; 761 description 762 "This container maintains a list of which additional notifications 763 should use which common headers if the receiver supports this 764 specification. The name starts with additional because there are 765 some mandatory common headers not listed in the container. These 766 headers are (1) message-time and (2) subscription-id."; 767 leaf-list additional-headers { 768 type common-header; 769 description 770 "This list contains the additional default headers which are to 771 be applied to each message from this publisher."; 772 } 773 list notification-specific-default { 774 key "module notification"; 775 description 776 "For any included notification, this list provides additional 777 common headers."; 778 uses notification-and-module; 779 leaf-list per-notification-headers { 780 type common-header; 781 description 782 "The set of additional default headers for a specific 783 notification."; 784 } 785 } 786 } 787 } 788 790 8. Backwards Compatibility 792 With this specification, there is no change to YANG's 'notification' 793 statement 795 Legacy clients are unaffected, and existing users of [RFC5277], 796 [RFC7950], and [RFC8040] are free to use current behaviors until all 797 involved device support this specification. 799 9. Security Considerations 801 Certain headers might be computationally complex for a publisher to 802 deliver. Signatures or encryption are two examples of this. It MUST 803 be possible to suspend or terminate a subscription due to lack of 804 resources based on this reason. 806 Decisions on whether to bundle or not to a receiver are fully under 807 the purview of the Publisher. A receiver could slow delivery to 808 existing subscriptions by creating new ones. (Which would result in 809 the publisher going into a bundling mode.) 811 10. Acknowledgments 813 For their valuable comments, discussions, and feedback, we wish to 814 acknowledge Martin Bjorklund, Einar Nilsen-Nygaard, and Kent Watsen. 816 11. References 818 11.1. Normative References 820 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 821 Requirement Levels", BCP 14, RFC 2119, 822 DOI 10.17487/RFC2119, March 1997, 823 . 825 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 826 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, 827 . 829 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 830 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 831 May 2017, . 833 [subscribe] 834 Voit, E., Clemm, A., Gonzalez Prieto, A., Prasad Tripathy, 835 A., and E. Nilsen-Nygaard, "Custom Subscription to Event 836 Notifications", September 2017, 837 . 840 11.2. Informative References 842 [http-push] 843 Voit, Eric., Clemm, Alexander., Tripathy, A., Nilsen- 844 Nygaard, E., and Alberto. Gonzalez Prieto, "Restconf and 845 HTTP transport for event notifications", August 2016, 846 . 849 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 850 and A. Bierman, Ed., "Network Configuration Protocol 851 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 852 . 854 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 855 RFC 7950, DOI 10.17487/RFC7950, August 2016, 856 . 858 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 859 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 860 . 862 [yang-push] 863 Clemm, A., Voit, E., Gonzalez Prieto, A., Prasad Tripathy, 864 A., and E. Nilsen-Nygaard, "Subscribing to YANG datastore 865 push updates", April 2017, 866 . 869 Appendix A. Changes between revisions 871 (To be removed by RFC editor prior to publication) 873 v01 - v02 875 o Fixed the yang-data encapsulation container issue 877 o Updated object definitions to point to RFC-7950 definitions 879 o Added headers for module and notification-type. 881 v00 - v01 883 o Alternative to 5277 one-way notification added 885 o Storage of default headers by notification type 887 o Backwards compatibility 889 o Capability discovery 890 o Move to yang-data 892 o Removed dscp and record-type as common headers. (Record type can 893 be determined by the namespace of the record contents. Dscp is 894 useful where applications need internal communications within a 895 Publisher, but it is unclear as to whether this use case need be 896 exposed to a receiver. 898 Appendix B. Issues being worked 900 (To be removed by RFC editor prior to publication) 902 Is this capability just for notifications, or is it for any yang-data 903 element too? 905 There is redundancy with module and notification in the headers, 906 along with the notification name and the namespace as the first 907 element of the pushed content. Do we remove one of them? 909 A complete JSON document is supposed to be sent as part of Media Type 910 "application/yang-data+json". As we are sending separate 911 notifications after eachother, we need to choose whether we start 912 with some extra encapsulation for the very first message pushed, or 913 if we want a new Media Type for streaming updates. 915 Improved discovery mechanisms for NETCONF 917 Do we want to have additional headers for a specific notification? 918 Right now this is included, but it could be excluded. 920 Should we defer support for HTTP2 configured subscriptions until this 921 draft is available? Without capabilities exchange, it might just be 922 easier to wait. In addition, JSON encoding still needs a 923 notification type which is not exising or represented in 924 referenceable in existing yang-models. 926 Need to ensure the proper references exist to a notification 927 definition driven by RFC-7950 which is acceptable to other eventual 928 users of this specification. 930 We need to link to Andy Bierman's anydata extensibility draft. 932 Appendix C. Subscription Specific Headers 934 (To be removed by RFC editor prior to publication) 936 This section discusses a future functional addition which could 937 leverage this draft. It is included for informational purposes only. 939 A dynamic subscriber might want to mandate that certain headers be 940 used for push updates from a publisher. Some examples of this 941 include a subscriber requesting to: 943 o establish this subscription, but just if transport messages 944 containing the pushed data will be encrypted, 946 o establish this subscription, but only if you can attest to the 947 information being delivered in requested notification records, or 949 o provide a sequence-id for all messages to this receiver (in order 950 to check for loss). 952 Providing this type of functionality would necessitate a new revision 953 of the [subscribe]'s RPCs and state change notifications. 954 Subscription specific header information would overwrite the default 955 headers identified in this document. 957 Appendix D. Implications to Existing RFCs 959 (To be removed by RFC editor prior to publication) 961 YANG one-way exchanges currently use a non-extensible header and 962 encoding defined in section 4 of RFC-5277. These RFCs MUST be 963 updated to enable this draft. These RFCs SHOULD be updated to 964 provide examples 966 D.1. Implications to RFC-7950 968 Sections which expose netconf:capability:notification:1.0 are 4.2.10 970 Sections which provide examples using netconf:notification:1.0 are 971 7.10.4, 7.16.3, and 9.9.6 973 D.2. Implications to RFC-8040 975 Section 6.4 demands use of RFC-5277's netconf:notification:1.0, and 976 later in the section provides an example. 978 Authors' Addresses 980 Eric Voit 981 Cisco Systems 983 Email: evoit@cisco.com 984 Andy Bierman 985 YumaWorks 987 Email: andy@yumaworks.com 989 Alexander Clemm 990 Huawei 992 Email: ludwig@clemm.org 994 Tim Jenkins 995 Cisco Systems 997 Email: timjenki@cisco.com