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