idnits 2.17.1 draft-ietf-netconf-notification-messages-08.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.) ** There are 5 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 240 has weird spacing: '...gorithm str...' == Line 244 has weird spacing: '...gorithm str...' -- The document date (November 15, 2019) is 1622 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: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF E. Voit 3 Internet-Draft T. Jenkins 4 Intended status: Standards Track Cisco Systems 5 Expires: May 18, 2020 H. Birkholz 6 Fraunhofer SIT 7 A. Bierman 8 YumaWorks 9 A. Clemm 10 Futurewei 11 November 15, 2019 13 Notification Message Headers and Bundles 14 draft-ietf-netconf-notification-messages-08 16 Abstract 18 This document defines a new notification message format. Included 19 are: 21 o a new notification mechanism and encoding to replace the one way 22 operation of RFC-5277 24 o a set of common, transport agnostic message header objects. 26 o how to bundle multiple event records into a single notification 27 message. 29 o how to ensure these new capabilities are only used with capable 30 receivers. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on May 18, 2020. 49 Copyright Notice 51 Copyright (c) 2019 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Header Objects . . . . . . . . . . . . . . . . . . . . . . . 3 69 4. Encapsulation of Header Objects in Messages . . . . . . . . . 4 70 4.1. One Notification per Message . . . . . . . . . . . . . . 4 71 4.2. Many Notifications per Message . . . . . . . . . . . . . 5 72 5. Configuration of Headers . . . . . . . . . . . . . . . . . . 8 73 6. Discovering Receiver Support . . . . . . . . . . . . . . . . 9 74 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 18 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 77 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 80 11.2. Informative References . . . . . . . . . . . . . . . . . 19 81 Appendix A. Changes between revisions . . . . . . . . . . . . . 19 82 Appendix B. Issues being worked . . . . . . . . . . . . . . . . 21 83 Appendix C. Subscription Specific Headers . . . . . . . . . . . 21 84 Appendix D. Implications to Existing RFCs . . . . . . . . . . . 22 85 D.1. Implications to RFC-7950 . . . . . . . . . . . . . . . . 22 86 D.2. Implications to RFC-8040 . . . . . . . . . . . . . . . . 22 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 89 1. Introduction 91 Mechanisms to support subscription to event notifications have been 92 defined in [RFC8639] and [RFC8641]. Work on those documents has 93 shown that notifications described in [RFC7950] section 7.16 could 94 benefit from transport independent headers. With such headers, 95 communicating the following information to receiving applications can 96 be done without explicit linkage to an underlying transport protocol: 98 o the time the notification was generated 100 o the time the notification was placed in a message and queued for 101 transport 103 o an identifier for the process generating the notification 105 o signatures to verify authenticity 107 o a subscription id which allows a notification be correlated with a 108 request for that notification 110 o multiple notifications bundled into one transportable message 112 o a message-id allowing a receiver to check for message loss/ 113 reordering 115 The document describes information elements needed for the functions 116 above. It also provides instances of YANG structures 117 [I-D.draft-ietf-netmod-yang-data-ext] for sending messages containing 118 one or more notifications to a receiver. 120 2. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in BCP 125 14 [RFC2119] [RFC8174] when, and only when, they appear in all 126 capitals, as shown here. 128 The definition of notification is in [RFC7950] Section 4.2.10. 129 Publisher, receiver, subscription, and event occurrence time are 130 defined in [RFC8639]. 132 3. Header Objects 134 There are a number of transport independent headers which should have 135 common definition. These include: 137 o subscription-id: provides a reference into the reason the 138 publisher believed the receiver wishes to be notified of this 139 specific information. 141 o notification-time: the origination time where a notification was 142 fully generated within the publisher. 144 o notification-id: Identifies an instance of an emitted notification 145 to a receiver. 147 o observation-domain-id: identifies the publisher process which 148 discovered and recorded the event notification. (note: look to 149 reuse the domains set up with IPFIX.) 151 o message-time: the time the message was packaged sent to the 152 transport layer for delivery to the receiver. 154 o signature: allows an application to sign a message so that a 155 receiver can verify the authenticity of the message. 157 o message-id: for a specific message generator, this identifies a 158 message which includes one or more event records. The message-id 159 increments by one with sequential messages. 161 o message-generator-id: identifier for the process which created the 162 message. This allows disambiguation of an information source, 163 such as the identification of different line cards sending the 164 messages. Used in conjunction with previous-message-id, this can 165 help find drops and duplications when messages are coming from 166 multiple sources on a device. If there is a message-generator-id 167 in the header, then the previous-message-id MUST be the message-id 168 from the last time that message-generator-id was sent. 170 4. Encapsulation of Header Objects in Messages 172 A specific set of well-known objects are of potential use to 173 networking layers prior being interpreted by some receiving 174 application layer process. By exposing this object information as 175 part of a header, and by using standardized object names, it becomes 176 possible for this object information to be leveraged in transit. 178 The objects defined in the previous section are these well-known 179 header objects. These objects are identified within a dedicated 180 header subtree which leads off a particular transportable message. 181 This allows header objects to be easily be decoupled, stripped, and 182 processed separately. 184 A receiver which supporting this document MUST be able to handle 185 receipt of either type of message from a publisher. 187 4.1. One Notification per Message 189 This section has been deleted from previous versions. It will be re- 190 instated if NETCONF WG members are not comfortable with the 191 efficiency of the solution which can encode many notifications per 192 message, as described below. 194 4.2. Many Notifications per Message 196 While possible in some scenarios, it often inefficient to marshal and 197 transport every notification independently. Instead, scale and 198 processing speed can be improved by placing multiple notifications 199 into one transportable bundle. 201 The format of this bundle appears in the YANG structure below, and is 202 fully defined in the YANG module. There are three parts of this 203 bundle: 205 o a message header describing the marshaling, including information 206 such as when the marshaling occurred 208 o a list of encapsulated information 210 o an optional message footer for whole-message signing and message- 211 generator integrity verification. 213 Within the list of encapsulated notifications, there are also three 214 parts: 216 o a notification header defining what is in an encapsulated 217 notification 219 o the actual notification itself 221 o an optional notification footer for individual notification 222 signing and observation-domain integrity verification. 224 structure message 225 +--ro message! 226 +--ro message-header 227 | +--ro message-time yang:date-and-time 228 | +--ro message-id? uint32 229 | +--ro message-generator-id? string 230 | +--ro notification-count? uint16 231 +--ro notifications* 232 | +--ro notification-header 233 | | +--ro notification-time yang:date-and-time 234 | | +--ro yang-module? yang:yang-identifier 235 | | +--ro subscription-id* uint32 236 | | +--ro notification-id? uint32 237 | | +--ro observation-domain-id? string 238 | +--ro notification-contents? 239 | +--ro notification-footer! 240 | +--ro signature-algorithm string 241 | +--ro signature-value string 242 | +--ro integrity-evidence? string 243 +--ro message-footer! 244 +--ro signature-algorithm string 245 +--ro signature-value string 246 +--ro integrity-evidence? string 248 An XML instance of a message might look like: 250 252 253 254 2017-02-14T00:00:05Z 255 256 257 456 258 259 260 2 261 262 263 264 265 266 2017-02-14T00:00:02Z 267 268 269 823472 270 271 272 ietf-yang-push 273 274 275 push-change-update 276 277 278 279 281 282 283 285 286 287 288 289 290 ...(notification header, contents, footer)... 291 292 293 295 5. Configuration of Headers 297 A publisher MUST select the set of headers to use within any 298 particular message. The two mandatory headers which MUST always be 299 applied are 'message-time' and 'subscription-id' 301 Beyond these two mandatory headers, additional headers MAY be 302 included. Configuration of what these optional headers should be can 303 come from the following sources: 305 1. Publisher wide default headers which are placed on all 306 notifications. An optional header is a publisher default if its 307 identity is included within the 'additional-headers' leaf-list. 309 2. More notification specific headers may also be desired. If new 310 headers are needed for a specific type of YANG notification, 311 these can be populated through 'additional-notification-headers' 312 leaf-list. 314 3. An application process may also identify common headers to use 315 when transporting notifications for a specific subscription. How 316 such application specific configuration is accomplished within 317 the publisher is out-of-scope. 319 The set of headers selected and populated for any particular message 320 is derived from the union of the mandatory headers and configured 321 optional headers. 323 The YANG tree showing elements of configuration is depicted in the 324 following figure. 326 module: ietf-notification-messages 327 +--rw additional-default-headers {publisher}? 328 +--rw additional-headers* optional-header 329 +--rw yang-notification-specific-default* 330 | [yang-module yang-notification-name] 331 +--rw yang-module yang:yang-identifier 332 +--rw yang-notification-name notification-type 333 +--rw additional-notification-headers* 334 optional-notification-header 336 Configuration Model structure 338 Of note in this tree is the optional feature of 'publisher'. This 339 feature indicates an ability to send notifications. A publisher 340 supporting this specification MUST also be able to parse any messages 341 received as defined in this document. 343 6. Discovering Receiver Support 345 We need capability exchange from the receiver to the publisher at 346 transport session initiation to indicate support for this 347 specification. 349 For all types of transport connections, if the receiver indicates 350 support for this specification, then it MAY be used. In addition, 351 [RFC5277] one-way notifications MUST NOT be used if the receiver 352 indicates support for this specification to a publisher which also 353 supports it. 355 Where NETCONF transport is used, advertising this specification's 356 namespace during an earlier client capabilities discovery phase MAY 357 be used to indicate support for this specification: 359 360 361 362 urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0 363 364 365 4 366 368 NOTE: It is understood that even though it is allowed in [RFC6241] 369 section 8.1, robust NETCONF client driven capabilities exchange is 370 not something which is common in implementation. Therefore reviewers 371 are asked to submit alternative proposals to the mailing list. 373 For RESTCONF, a mechanism for capability discovery is TBD. Proposals 374 are welcome here. 376 The mechanism described above assumes that a capability discovery 377 phase happens before a subscription is started. This is not always 378 the case. There is no guarantee that a capability exchange has taken 379 place before the messages are emitted. A solution for this in the 380 case of HTTP based transport could be that a receiver would have to 381 reply "ok" and also return the client capabilities as part a response 382 to the initiation of the POST. 384 7. YANG Module 386 file "ietf-notification-messages@2019-10-10.yang" 387 module ietf-notification-messages { 388 yang-version 1.1; 389 namespace 390 "urn:ietf:params:xml:ns:yang:ietf-notification-messages"; 391 prefix nm; 393 import ietf-yang-types { prefix yang; } 394 import ietf-yang-structure-ext { prefix sx; } 396 organization "IETF"; 397 contact 398 "WG Web: 399 WG List: 401 Editor: Eric Voit 402 404 Editor: Henk Birkholz 405 407 Editor: Alexander Clemm 408 410 Editor: Andy Bierman 411 413 Editor: Tim Jenkins 414 "; 416 description 417 "This module contains conceptual YANG specifications for 418 messages carrying notifications with well-known header objects."; 420 revision 2019-10-10 { 421 description 422 "Initial version."; 424 reference 425 "draft-ietf-netconf-notification-messages-08"; 426 } 428 /* 429 * FEATURES 430 */ 432 feature publisher { 433 description 434 "This feature indicates that support for both publisher and 435 receiver of messages complying to the specification."; 436 } 437 /* 438 * IDENTITIES 439 */ 441 /* Identities for common headers */ 443 identity common-header { 444 description 445 "A well-known header which can be included somewhere within a 446 message."; 447 } 449 identity message-time { 450 base common-header; 451 description 452 "Header information consisting of time the message headers were 453 generated prior to being sent to transport"; 454 } 456 identity subscription-id { 457 base common-header; 458 description 459 "Header information consisting of the identifier of the 460 subscription associated with the notification being 461 encapsulated."; 462 } 464 identity notification-count { 465 base common-header; 466 description 467 "Header information consisting of the quantity of notifications in 468 a bundled-message for a specific receiver."; 469 } 471 identity optional-header { 472 base common-header; 473 description 474 "A well-known header which an application may choose to include 475 within a message."; 476 } 478 identity message-id { 479 base optional-header; 480 description 481 "Header information that identifies a message to a specific 482 receiver"; 483 } 484 identity message-generator-id { 485 base optional-header; 486 description 487 "Header information consisting of an identifier for a software 488 entity which created the message (e.g., linecard 1)."; 489 } 491 identity message-signature { 492 base optional-header; 493 description 494 "Identifies two elements of header information consisting of a 495 signature and the signature type for the contents of a message. 496 Signatures can be useful for originating applications to 497 verify record contents even when shipping over unsecure 498 transport."; 499 } 501 identity message-integrity-evidence { 502 base optional-header; 503 description 504 "Header information consisting of the information which backs up 505 the assertions made as to the validity of the information 506 provided within the message."; 507 } 509 identity optional-notification-header { 510 base optional-header; 511 description 512 "A well-known header which an application may choose to include 513 within a message."; 514 } 516 identity notification-time { 517 base optional-notification-header; 518 description 519 "Header information consisting of the time an originating process 520 created the notification."; 521 } 523 identity notification-id { 524 base optional-notification-header; 525 description 526 "Header information consisting of an identifier for an instance 527 of a notification. If access control based on a message's receiver may 528 strip information from within the notification, this notification-id MUST 529 allow the identification of the specific contents of notification as it 530 exits the publisher."; 532 } 534 identity observation-domain-id { 535 base optional-notification-header; 536 description 537 "Header information identifying the software entity which created 538 the notification (e.g., process id)."; 539 } 541 identity notification-signature { 542 base optional-notification-header; 543 description 544 "Header information consisting of a signature which can be used to prove 545 the authenticity that some asserter validates over the information 546 provided within the notification."; 547 } 549 identity notification-integrity-evidence { 550 base optional-notification-header; 551 description 552 "Header information consisting of the information which backs up 553 the assertions made as to the validity of the information 554 provided within the notification."; 555 } 557 /* 558 * TYPEDEFs 559 */ 561 typedef optional-header { 562 type identityref { 563 base optional-header; 564 } 565 description 566 "Type of header object which may be included somewhere within a 567 message."; 568 } 570 typedef optional-notification-header { 571 type identityref { 572 base optional-notification-header; 573 } 574 description 575 "Type of header object which may be included somewhere within a 576 message."; 577 } 578 typedef notification-type { 579 type string { 580 pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*'; 581 } 582 description 583 "The name of a notification within a YANG module."; 584 reference 585 "RFC-7950 Section 7.16"; 586 } 588 /* 589 * GROUPINGS 590 */ 592 grouping message-header { 593 description 594 "Header information included with a message."; 595 leaf message-time { 596 type yang:date-and-time; 597 mandatory true; 598 description 599 "Time the message was generated prior to being sent to 600 transport."; 601 } 602 leaf message-id { 603 type uint32; 604 description 605 "Id for a message going to a receiver from a message 606 generator. The id will increment by one with each message sent 607 from a particular message generator, allowing the message-id 608 to be used as a sequence number."; 609 } 610 leaf message-generator-id { 611 type string; 612 description 613 "Software entity which created the message (e.g., linecard 1). 614 The combination of message-id and message-generator-id must be 615 unique until reset or a roll-over occurs."; 616 } 617 leaf notification-count { 618 type uint16; 619 description 620 "Quantity of notifications in a bundled-message to a 621 specific receiver."; 622 } 623 } 625 grouping notification-header { 626 description 627 "Common informational objects which might help a receiver 628 interpret the meaning, details, or importance of a notification."; 629 leaf notification-time { 630 type yang:date-and-time; 631 mandatory true; 632 description 633 "Time the system recognized the occurrence of an event."; 634 } 635 leaf yang-module { 636 type yang:yang-identifier; 637 description 638 "Name of the YANG module supported by the publisher."; 639 } 640 leaf-list subscription-id { 641 type uint32; 642 description 643 "Id of the subscription which led to the notification being 644 generated."; 645 } 646 leaf notification-id { 647 type uint32; 648 description 649 "Identifier for the notification record."; 650 } 651 leaf observation-domain-id { 652 type string; 653 description 654 "Software entity which created the notification record (e.g., 655 process id)."; 656 } 657 } 659 grouping security-footer { 660 description 661 "Reusable grouping for common objects which apply to the signing of 662 notifications or messages."; 663 leaf signature-algorithm { 664 type string; 665 mandatory true; 666 description 667 "The technology with which an originator signed of some 668 delineated contents."; 669 } 670 leaf signature-value { 671 type string; 672 mandatory true; 673 description 674 "Any originator signing of the contents of a header and 675 content. This is useful for verifying contents even when 676 shipping over unsecure transport."; 677 } 678 leaf integrity-evidence { 679 type string; 680 description 681 "This mechanism allows a verifier to ensure that the use of the 682 private key, represented by the corresponding public key 683 certificate, was performed with a TCG compliant TPM 684 environment. This evidence is never included in within any 685 signature."; 686 reference 687 "TCG Infrastructure Workgroup, Subject Key Attestation Evidence 688 Extension, Specification Version 1.0, Revision 7."; 689 } 690 } 692 /* 693 * YANG encoded structures which can be sent to receivers 694 */ 696 sx:structure message { 697 container message-header { 698 description 699 "Header info for messages."; 700 uses message-header; 701 } 702 list notifications { 703 description 704 "Set of notifications to a receiver."; 705 container notification-header { 706 description 707 "Header info for a notification."; 708 uses notification-header; 709 } 710 anydata notification-contents { 711 description 712 "Encapsulates objects following YANG's notification-stmt 713 grammar of RFC-7950 section 14. Within are the notified 714 objects the publisher actually generated in order to be 715 passed to a receiver after all filtering has completed."; 716 } 717 container notification-footer { 718 presence 719 "Indicates attempt to secure a notification."; 720 description 721 "Signature and evidence for messages."; 723 uses security-footer; 724 } 725 } 726 container message-footer { 727 presence 728 "Indicates attempt to secure the entire message."; 729 description 730 "Signature and evidence for messages."; 731 uses security-footer; 732 } 733 } 735 /* 736 * DATA-NODES 737 */ 739 container additional-default-headers { 740 if-feature "publisher"; 741 description 742 "This container maintains a list of which additional notifications 743 should use which optional headers if the receiver supports this 744 specification."; 745 leaf-list additional-headers { 746 type optional-header; 747 description 748 "This list contains the identities of the optional header types 749 which are to be included within each message from this 750 publisher."; 751 } 752 list yang-notification-specific-default { 753 key "yang-module yang-notification-name"; 754 description 755 "For any included YANG notifications, this list provides 756 additional optional headers which should be placed within the 757 container notification-header if the receiver supports this 758 specification. This list incrementally adds to any headers 759 indicated within the leaf-list 'additional-headers'."; 760 leaf yang-module { 761 type yang:yang-identifier; 762 description 763 "Name of the YANG module supported by the publisher."; 764 } 765 leaf yang-notification-name { 766 type notification-type; 767 description 768 "The name of a notification within a YANG module."; 769 } 770 leaf-list additional-notification-headers { 771 type optional-notification-header; 772 description 773 "The set of additional default headers which will be sent 774 for a specific notification."; 775 } 776 } 777 } 778 } 780 782 8. Backwards Compatibility 784 With this specification, there is no change to YANG's 'notification' 785 statement 787 Legacy clients are unaffected, and existing users of [RFC5277], 788 [RFC7950], and [RFC8040] are free to use current behaviors until all 789 involved device support this specification. 791 9. Security Considerations 793 Certain headers might be computationally complex for a publisher to 794 deliver. Signatures or encryption are two examples of this. It MUST 795 be possible to suspend or terminate a subscription due to lack of 796 resources based on this reason. 798 Decisions on whether to bundle or not to a receiver are fully under 799 the purview of the Publisher. A receiver could slow delivery to 800 existing subscriptions by creating new ones. (Which would result in 801 the publisher going into a bundling mode.) 803 10. Acknowledgments 805 For their valuable comments, discussions, and feedback, we wish to 806 acknowledge Martin Bjorklund, Einar Nilsen-Nygaard, and Kent Watsen. 808 11. References 810 11.1. Normative References 812 [I-D.draft-ietf-netmod-yang-data-ext] 813 Bierman, A., Bjorklund, M., and K. Watsen, "YANG Data 814 Structure Extensions", draft-ietf-netmod-yang-data-ext 815 (work in progress), July 2019. 817 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 818 Requirement Levels", BCP 14, RFC 2119, 819 DOI 10.17487/RFC2119, March 1997, 820 . 822 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 823 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, 824 . 826 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 827 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 828 May 2017, . 830 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 831 E., and A. Tripathy, "Subscription to YANG Notifications", 832 RFC 8639, DOI 10.17487/RFC8639, September 2019, 833 . 835 11.2. Informative References 837 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 838 and A. Bierman, Ed., "Network Configuration Protocol 839 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 840 . 842 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 843 RFC 7950, DOI 10.17487/RFC7950, August 2016, 844 . 846 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 847 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 848 . 850 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 851 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 852 September 2019, . 854 Appendix A. Changes between revisions 856 (To be removed by RFC editor prior to publication) 858 v06 - v08 860 o Removed redundant container from message 862 o References and example updates 864 v05 - v06 865 o With SN and YP getting RFC numbers, revisiting this document. 867 o Changed yang-data to draft-ietf-netmod-yang-data-ext's 868 'structure'. 870 o Removed the ability to reference structures other than YANG 871 notifications. 873 v04 - v05 875 o Revision before expiration. Awaiting closure of SN and YP prior 876 to update. 878 v03 - v04 880 o Terminology tweaks. 882 o Revision before expiration. Awaiting closure of SN prior to 883 update. 885 v02 - v03 887 o Removed the option for an unbundled message. This might be re- 888 added later for transport efficiency if desired by the WG 890 o New message structure driven by the desire to put the signature 891 information at the end. 893 v01 - v02 895 o Fixed the yang-data encapsulation container issue 897 o Updated object definitions to point to RFC-7950 definitions 899 o Added headers for module and notification-type. 901 v00 - v01 903 o Alternative to 5277 one-way notification added 905 o Storage of default headers by notification type 907 o Backwards compatibility 909 o Capability discovery 911 o Move to yang-data 912 o Removed dscp and record-type as common headers. (Record type can 913 be determined by the namespace of the record contents. Dscp is 914 useful where applications need internal communications within a 915 Publisher, but it is unclear as to whether this use case need be 916 exposed to a receiver. 918 Appendix B. Issues being worked 920 (To be removed by RFC editor prior to publication) 922 A complete JSON document is supposed to be sent as part of Media Type 923 "application/yang-data+json". As we are sending separate 924 notifications after each other, we need to choose whether we start 925 with some extra encapsulation for the very first message pushed, or 926 if we want a new Media Type for streaming updates. 928 Improved discovery mechanisms for NETCONF 930 Need to ensure the proper references exist to a notification 931 definition driven by RFC-7950 which is acceptable to other eventual 932 users of this specification. 934 Appendix C. Subscription Specific Headers 936 (To be removed by RFC editor prior to publication) 938 This section discusses a future functional addition which could 939 leverage this draft. It is included for informational purposes only. 941 A dynamic subscriber might want to mandate that certain headers be 942 used for push updates from a publisher. Some examples of this 943 include a subscriber requesting to: 945 o establish this subscription, but just if transport messages 946 containing the pushed data will be encrypted, 948 o establish this subscription, but only if you can attest to the 949 information being delivered in requested notification records, or 951 o provide a sequence-id for all messages to this receiver (in order 952 to check for loss). 954 Providing this type of functionality would necessitate a new revision 955 of the [RFC8639]'s RPCs and state change notifications. Subscription 956 specific header information would overwrite the default headers 957 identified in this document. 959 Appendix D. Implications to Existing RFCs 961 (To be removed by RFC editor prior to publication) 963 YANG one-way exchanges currently use a non-extensible header and 964 encoding defined in section 4 of RFC-5277. These RFCs MUST be 965 updated to enable this draft. These RFCs SHOULD be updated to 966 provide examples 968 D.1. Implications to RFC-7950 970 Sections which expose netconf:capability:notification:1.0 are 4.2.10 972 Sections which provide examples using netconf:notification:1.0 are 973 7.10.4, 7.16.3, and 9.9.6 975 D.2. Implications to RFC-8040 977 Section 6.4 demands use of RFC-5277's netconf:notification:1.0, and 978 later in the section provides an example. 980 Authors' Addresses 982 Eric Voit 983 Cisco Systems 985 Email: evoit@cisco.com 987 Tim Jenkins 988 Cisco Systems 990 Email: timjenki@cisco.com 992 Henk Birkholz 993 Fraunhofer SIT 995 Email: henk.birkholz@sit.fraunhofer.de 997 Andy Bierman 998 YumaWorks 1000 Email: andy@yumaworks.com 1001 Alexander Clemm 1002 Futurewei 1004 Email: ludwig@clemm.org