idnits 2.17.1 draft-ietf-netconf-notification-messages-01.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 (September 29, 2017) is 2401 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 2, 2018 YumaWorks 6 A. Clemm 7 Huawei 8 T. Jenkins 9 Cisco Systems 10 September 29, 2017 12 Notification Message Headers and Bundles 13 draft-ietf-netconf-notification-messages-01 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 2, 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 . . . . . . . . . . . . . . 9 72 5. Configuration of Headers . . . . . . . . . . . . . . . . . . 9 73 6. Discovering Receiver Support . . . . . . . . . . . . . . . . 10 74 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 17 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . 19 83 Appendix C. Subscription Specific Headers . . . . . . . . . . . 20 84 Appendix D. Implications to Existing RFCs . . . . . . . . . . . 20 85 D.1. Implications to RFC-7950 . . . . . . . . . . . . . . . . 20 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 (wheterh this is in scope is tbd). 144 o observation-domain-id: identifies the publisher process which 145 discovered and recorded the event notification. (note: look to 146 reuse the domains set up with IPFIX.) 148 o message-time: the time the message was packaged sent to the 149 transport layer for delivery to the receiver. 151 o signature: allows an application to sign a message so that a 152 receiver can verify the authenticity of the message. 154 o message-id: for a specific message generator, this identifies a 155 message which includes one or more event records. 157 o previous-message-id: the message-id of the message preceding the 158 current one intended for the same receiver. When used in 159 conjunction with the current message-id, this allows loss/ 160 duplication across previous messages to be discovered. If there 161 was no previous message from a message generator, the reserved id 162 "0" must be sent. 164 o message-generator-id: identifier for the process which created the 165 message. This allows disambiguation of an information source, 166 such as the identification of different line cards sending the 167 messages. Used in conjunction with previous-message-id, this can 168 help find drops and duplications when messages are coming from 169 multiple sources on a device. If there is a message-generator-id 170 in the header, then the previous-message-id MUST be the message-id 171 from the last time that message-generator-id was sent. 173 4. Encapsulation of Header Objects in Messages 175 A specific set of well-known objects are of potential use to 176 networking layers prior being interpreted by some receiving 177 application layer process. By exposing this object information as 178 part of a header, and by using standardized object names, it becomes 179 possible for this object information to be leveraged in transit. 181 The objects defined in the previous section are these well-known 182 header objects. These objects are identified within a dedicated 183 header subtree which leads off a particular transportable message. 184 This allows header objects to be easily be decoupled, stripped, and 185 processed separately. 187 There are two types of transportable messages: one format is used 188 when there is one notification being encapsulated, and another format 189 used when there are many notifications being bundled into one 190 message. 192 A receiver which supporting this document MUST be able to handle 193 receipt of either type of message from an publisher. It is possible 194 that changes between message types can occur without any prior 195 indication. 197 4.1. One Notification per Message 199 Below are contents of a message when there is only one notification 200 in an encapsulated and encoded message: 202 yang-data message 203 +-- message-header 204 | +-- notification-time yang:date-and-time 205 | +-- subscription-id* uint32 206 | +-- notification-id? uint32 207 | +-- observation-domain-id? string 208 | +-- message-id? uint32 209 | +-- message-time? yang:date-and-time 210 | +-- previous-message-id? uint32 211 | +-- message-generator-id? string 212 | +-- signature? string 213 +-- receiver-record-contents? 215 An actual instance of such a message when encoded in XML might look 216 like: 218 220 221 222 2017-02-14T00:00:02Z 223 224 225 823472 226 227 228 2017-02-14T00:00:05Z 229 230 231 456 232 233 234 567 235 236 237 lKIo8s03fd23..... 238 239 240 242 243 244 246 247 248 249 251 4.2. Many Notifications per Message 253 In many implementations, it may be inefficient to transport every 254 notification independently. Instead, scale and processing speed can 255 be improved by placing multiple notifications into one transportable 256 bundle. 258 When this is done, one additional header field becomes valuable. 259 This is the "notification-count" which would tally the quantity of 260 records which make up the contents of the bundle. It is true that 261 the record count can be derived, but early access to this information 262 could change receiver processing. 264 The format of a bundle would look as below. When compared to the 265 unbundled notification, note that the headers have been split so that 266 one set of headers associated with the notification occur once at the 267 beginning of the message, and additional record specific headers 268 which occur before individual records. 270 yang-data bundled-message 271 +-- bundled-message-header 272 | +-- message-time yang:date-and-time 273 | +-- message-id? uint32 274 | +-- previous-message-id? uint32 275 | +-- message-generator-id? string 276 | +-- signature? string 277 | +-- notification-count? uint16 278 +-- notifications* 279 +-- notification-header 280 | +-- notification-time yang:date-and-time 281 | +-- subscription-id* uint32 282 | +-- notification-id? uint32 283 | +-- observation-domain-id? string 284 +-- receiver-record-contents? 286 An actual instance of a bundled notification might look like: 288 290 291 292 2017-02-14T00:00:05Z 293 294 295 456 296 297 298 567 299 300 301 lKIo8s03fd23... 302 303 304 2 305 306 307 308 309 310 311 2017-02-14T00:00:02Z 312 313 314 823472 315 316 317 319 320 321 323 324 325 326 327 328 ...(record #2)... 329 330 331 333 4.3. Notification Type in Payload 335 The type of notification transported within a record could be a 336 header. However the notification name and namespace is the first 337 element in the receiver record contents payload. As this can be 338 determined by the YANG module containing the notification-stmt as 339 represented within the first part of the encapsulated notification 340 message, this information need not replicated within a header. 342 5. Configuration of Headers 344 A publisher MUST select the set of headers to use for a particular 345 message. The two mandatory headers which MUST always be applied to 346 every message are 'message-time' and 'subscription-id' 348 Beyond these two mandatory headers, the following are additional 349 sources which can add common headers to a message. 351 1. Publisher wide default headers for all notifications. These are 352 included if a common header is inserted into 'additional-headers' 353 shown in the figure below. 355 2. More notification specific headers may also be desired. If new 356 headers are needed for a specific notification in the YANG model, 357 this can be populated through 'per-notification-headers'. 359 3. An application process may also identify common headers to use 360 when transporting notifications for a specific subscription. How 361 these are identified to a publisher is out-of-scope. 363 The set of headers used for any particular message is the superset of 364 headers for the items listed above. 366 The YANG tree showing elements of configuration is depicted in the 367 following figure. 369 module: ietf-notification-messages 370 +--rw additional-default-headers {publisher}? 371 +--rw additional-headers* common-header 372 +--rw notification-specific-default* [module notification] 373 +--rw module yang:yang-identifier 374 +--rw notification string 375 +--rw per-notification-headers* common-header 377 Configuration Model structure 379 Of note in this tree is the optional feature of 'publisher'. This 380 feature indicates an ability to send notifications. A publisher 381 supporting this specification MUST also be able to parse any messages 382 received as defined in this document. 384 6. Discovering Receiver Support 386 We need capability exchange from the receiver to the publisher at 387 transport session initiation to indicate support for this 388 specification. 390 For all types of transport connections, if the receiver indicates 391 support for this specification, then it MAY be used. In addition, 392 [RFC5277] one-way notifications MUST NOT be used if the receiver 393 indicates support for this specification to a publisher which also 394 supports it. 396 Where NETCONF transport is used, advertising this specification's 397 namespace during an earlier client capabilities discovery phase MAY 398 be used to indicate support for this specification: 400 401 402 403 urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0 404 405 406 4 407 409 NOTE: It is understood that even though it is allowed in [RFC6241] 410 section 8.1, robust NETCONF client driven capabilities exchange is 411 not something which is common in implementation. Therefore reviewers 412 are asked to submit alternative proposals to the mailing list. 414 For RESTCONF, a mechanism for capability discovery is TBD. Proposals 415 are also welcome here. 417 The mechanism described above assumes that a capability discovery 418 phase happens before a subscription is started. This is not always 419 the case. As an example, consider HTTP2 configured subscriptions 420 from section 3.1.3 of [http-push], there is no guarantee that a 421 capability exchange has taken place before the updates are pushed. A 422 solution for this could be that a receiver would reply "ok" and reply 423 with the client capabilities as part of the POST. (Or just use a 424 different HTTP status code like 202 instead of 200 'ok'). As such a 425 requirement creates a new dependency for [http-push] upon this 426 specification, more discussion is required to decide if this is a 427 viable solution. 429 7. YANG Module 431 file "ietf-notification-messages.yang" 432 module ietf-notification-messages { 433 yang-version 1.1; 434 namespace 435 "urn:ietf:params:xml:ns:yang:ietf-notification-messages"; 436 prefix nm; 438 import ietf-yang-types { prefix yang; } 439 import ietf-restconf { prefix rc; } 441 organization "IETF"; 442 contact 443 "WG Web: 444 WG List: 446 Editor: Eric Voit 447 449 Editor: Alexander Clemm 450 452 Editor: Andy Bierman 453 455 Editor: Tim Jenkins 456 "; 458 description 459 "This module contains conceptual YANG specifications for yang-data 460 messages carrying notifications with well known header objects."; 462 revision 2017-09-28 { 463 description 464 "Initial version."; 466 reference 467 "draft-ietf-netconf-notification-messages-01"; 468 } 470 /* 471 * FEATURES 472 */ 474 feature publisher { 475 description 476 "This feature indicates that support for both publisher and 477 receiver of messages complying to the specification."; 478 } 480 /* 481 * IDENTITIES 482 */ 484 /* Identities for common headers */ 486 identity common-header { 487 description 488 "A well known header which can be included somewhere within a 489 message."; 490 } 492 identity notification-time { 493 base common-header; 494 description 495 "Header information consisting of the time an originating process 496 created the notification or yang-data."; 497 } 499 identity notification-id { 500 base common-header; 501 description 502 "Header information consisting of an identifier for the 503 notification or yang-data record. "; 504 } 506 identity subscription-id { 507 base common-header; 508 description 509 "Header information consisting of the identifier of the 510 subscription associated with the notification or yang-data being 511 encapsulated."; 512 } 514 identity observation-domain-id { 515 base common-header; 516 description 517 "Header information identifying the software entity which created 518 the notification or yang-data (e.g., process id)."; 519 } 521 identity message-id { 522 base common-header; 523 description 524 "Header information that identifies a message to a specific 525 receiver"; 526 } 528 identity message-time { 529 base common-header; 530 description 531 "Header information consisting of time the message headers were 532 placed generated prior to being sent to transport"; 533 } 535 identity previous-message-id { 536 base common-header; 537 description 538 "Header information consisting of a message id previously sent by 539 the publisher to a specific receiver (allows detection of 540 loss/duplication)."; 541 } 543 identity message-generator-id { 544 base common-header; 545 description 546 "Header information consisting of an identifier for a software 547 entity which created the message (e.g., linecard 1)."; 548 } 550 identity signature { 551 base common-header; 552 description 553 "Header information consisting of a signature on the contents of 554 a message. This can be useful for originating applications to 555 verify record contents even when shipping over unsecure 556 transport."; 557 } 559 identity notification-count { 560 base common-header; 561 description 562 "Header information consisting of the quantity of notifications in 563 a bundled-message for a specific receiver."; 564 } 566 /* 567 * TYPEDEFs 568 */ 570 typedef common-header { 571 type identityref { 572 base common-header; 573 } 574 description 575 "Type of header object which may be included somewhere within a 576 message."; 577 } 579 /* 580 * GROUPINGS 581 */ 583 grouping message-header { 584 description 585 "Header information included with a message."; 586 leaf message-id { 587 type uint32; 588 description 589 "Unique id for a message going to a receiver."; 590 } 591 leaf message-time { 592 type yang:date-and-time; 593 description 594 "time the message was generated prior to being sent to 595 transport."; 596 } 597 leaf previous-message-id { 598 type uint32; 599 description 600 "message id previously sent by publisher to a specific 601 receiver (allows detection of loss/duplication)."; 602 } 603 leaf message-generator-id { 604 type string; 605 description 606 "Software entity which created the message (e.g., linecard 1)."; 607 } 608 leaf signature { 609 type string; 610 description 611 "Any originator signing of the contents of a message. This can 612 be useful for originating applications to verify record contents 613 even when shipping over unsecure transport."; 614 } 615 } 617 grouping notification-header { 618 description 619 "Common informational objects which might help a receiver 620 interpret the meaning, details, or importance of a notification."; 621 leaf notification-time { 622 type yang:date-and-time; 623 mandatory true; 624 description 625 "Time the system recognized the occurrence of an event."; 626 } 627 leaf-list subscription-id { 628 type uint32; 629 description 630 "Id of the subscription which led to the notification being 631 generated."; 632 } 633 leaf notification-id { 634 type uint32; 635 description 636 "Identifier for the notification record."; 637 } 638 leaf observation-domain-id { 639 type string; 640 description 641 "Software entity which created the notification record (e.g., 642 process id)."; 643 } 644 } 646 /* 647 * YANG-DATA messages for receivers 648 */ 650 /* Message to a receiver containing one notification.*/ 651 rc:yang-data message { 652 container message-header { 653 description 654 "delineates header info from content for easy parsing."; 655 uses notification-header; 656 uses message-header; 657 } 658 anydata notification-contents { 659 description 660 "Non-header info of what actually got sent to receiver. This 661 includes after any content based security filtering. Need to 662 determine if/how it is viable not to include tag encapsulation 663 for this object."; 664 } 665 } 667 /* Message to a receiver containing many bundled notifications.*/ 668 rc:yang-data bundled-message { 669 container bundled-message-header { 670 description 671 "Header info for messages."; 672 uses message-header { 673 refine message-time { 674 mandatory true; 675 } 676 } 677 leaf notification-count { 678 type uint16; 679 description 680 "Quantity of notification records in a bundled-message 681 specific receiver."; 682 } 683 } 684 list notifications { 685 description 686 "Set of notifications to a receiver."; 687 container notification-header { 688 description 689 "Header info for each bundled notification."; 690 uses notification-header; 691 } 692 anydata notification-contents { 693 description 694 "Non-header info of what actually got sent to receiver. This 695 includes after any content based security filtering. Need to 696 determine if/how it is viable not to include tag encapsulation 697 for this object."; 698 } 699 } 700 } 702 /* 703 * DATA-NODES 704 */ 706 container additional-default-headers { 707 if-feature "publisher"; 708 description 709 "This container maintains a list of which additional notifications 710 should use which common headers if the receiver supports this 711 specification. The name starts with additional because there are 712 some mandatory common headers not listed in the container. These 713 headers are (1) message-time and (2) subscription-id."; 714 leaf-list additional-headers { 715 type common-header; 716 description 717 "This list contains the additional default headers which are to 718 be applied to each message from this publisher."; 719 } 720 list notification-specific-default { 721 key "module notification"; 722 description 723 "For any included notification, this list provides additional 724 common headers."; 725 leaf module { 726 type yang:yang-identifier; 727 description 728 "Name of the module containing a notification."; 729 } 730 leaf notification { 731 type string { 732 pattern 'notification $|yang-data $'; 733 } 734 description 735 "The name of the notification or yang-data being sent."; 736 } 737 leaf-list per-notification-headers { 738 type common-header; 739 description 740 "The set of additional default headers for a specific 741 notification."; 742 } 743 } 744 } 745 } 746 748 8. Backwards Compatibility 750 With this specification, there is no change to YANG's 'notification' 751 statement 753 Legacy clients are unaffected, and existing users of [RFC5277], 754 [RFC7950], and [RFC8040] are free to use current behaviors until all 755 involved device support this specification. 757 9. Security Considerations 759 Certain headers might be computationally complex for a publisher to 760 deliver. Signatures or encryption are two examples of this. It MUST 761 be possible to suspend or terminate a subscription due to lack of 762 resources based on this reason. 764 Decisions on whether to bundle or not to a receiver are fully under 765 the purview of the Publisher. A receiver could slow delivery to 766 existing subscriptions by creating new ones. (Which would result in 767 the publisher going into a bundling mode.) 769 10. Acknowledgments 771 For their valuable comments, discussions, and feedback, we wish to 772 acknowledge Martin Bjorklund and Kent Watsen. 774 11. References 776 11.1. Normative References 778 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 779 Requirement Levels", BCP 14, RFC 2119, 780 DOI 10.17487/RFC2119, March 1997, 781 . 783 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 784 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, 785 . 787 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 788 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 789 May 2017, . 791 [subscribe] 792 Voit, E., Clemm, A., Gonzalez Prieto, A., Prasad Tripathy, 793 A., and E. Nilsen-Nygaard, "Custom Subscription to Event 794 Notifications", September 2017, 795 . 798 11.2. Informative References 800 [http-push] 801 Voit, Eric., Clemm, Alexander., Tripathy, A., Nilsen- 802 Nygaard, E., and Alberto. Gonzalez Prieto, "Restconf and 803 HTTP transport for event notifications", August 2016, 804 . 807 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 808 and A. Bierman, Ed., "Network Configuration Protocol 809 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 810 . 812 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 813 RFC 7950, DOI 10.17487/RFC7950, August 2016, 814 . 816 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 817 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 818 . 820 [yang-push] 821 Clemm, A., Voit, E., Gonzalez Prieto, A., Prasad Tripathy, 822 A., and E. Nilsen-Nygaard, "Subscribing to YANG datastore 823 push updates", April 2017, 824 . 827 Appendix A. Changes between revisions 829 (To be removed by RFC editor prior to publication) 831 v00 - v01 833 o Alternative to 5277 one-way notification added 835 o Storage of default headers by notification type 837 o Backwards compatibility 839 o Capability discovery 841 o Move to yang-data 843 o Removed dscp and record-type as common headers. (Record type can 844 be determined by the namespace of the record contents. Dscp is 845 useful where applications need internal communications within a 846 Publisher, but it is unclear as to whether this use case need be 847 exposed to a receiver. 849 Appendix B. Issues being worked 851 (To be removed by RFC editor prior to publication) 853 Is this capability just for notifications, or is it for any yang-data 854 element too? 856 Improved discovery mechanisms for NETCONF 858 Do we want to have additional headers for a specific notification? 859 Right now this is included, but it could be excluded. 861 Should we defer support for HTTP2 configured subscriptions until this 862 draft is available? Without capabilities exchange, it might just be 863 easier to wait. 865 Encoding of notification-contents so that individual notification 866 framing isn't needed. 868 We need to link to Andy Bierman's anydata extensibility draft. 870 Appendix C. Subscription Specific Headers 872 (To be removed by RFC editor prior to publication) 874 This section discusses a future functional addition which could 875 leverage this draft. It is included for informational purposes only. 877 A dynamic subscriber might want to mandate that certain headers be 878 used for push updates from a publisher. Some examples of this 879 include a subscriber requesting to: 881 o establish this subscription, but just if transport messages 882 containing the pushed data will be encrypted, 884 o establish this subscription, but only if you can attest to the 885 information being delivered in requested notification records, or 887 o provide a sequence-id for all messages to this receiver (in order 888 to check for loss). 890 Providing this type of functionality would necessitate a new revision 891 of the [subscribe]'s RPCs and state change notifications. 892 Subscription specific header information would overwrite the default 893 headers identified in this document. 895 Appendix D. Implications to Existing RFCs 897 (To be removed by RFC editor prior to publication) 899 YANG one-way exchanges currently use a non-extensible header and 900 encoding defined in section 4 of RFC-5277. These RFCs MUST be 901 updated to enable this draft. These RFCs SHOULD be updated to 902 provide examples 904 D.1. Implications to RFC-7950 906 Sections which expose netconf:capability:notification:1.0 are 4.2.10 907 Sections which provide examples using netconf:notification:1.0 are 908 7.10.4, 7.16.3, and 9.9.6 910 D.2. Implications to RFC-8040 912 Section 6.4 demands use of RFC-5277's netconf:notification:1.0, and 913 later in the section provides an example. 915 Authors' Addresses 917 Eric Voit 918 Cisco Systems 920 Email: evoit@cisco.com 922 Andy Bierman 923 YumaWorks 925 Email: andy@yumaworks.com 927 Alexander Clemm 928 Huawei 930 Email: ludwig@clemm.org 932 Tim Jenkins 933 Cisco Systems 935 Email: timjenki@cisco.com