idnits 2.17.1 draft-ietf-netconf-notification-messages-04.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 == Line 249 has weird spacing: '...gorithm str...' == Line 253 has weird spacing: '...gorithm str...' -- The document date (August 22, 2018) is 2073 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) == Outdated reference: A later version (-26) exists of draft-ietf-netconf-subscribed-notifications-16 Summary: 1 error (**), 0 flaws (~~), 4 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 23, 2019 Fraunhofer SIT 6 A. Bierman 7 YumaWorks 8 A. Clemm 9 Huawei 10 T. Jenkins 11 Cisco Systems 12 August 22, 2018 14 Notification Message Headers and Bundles 15 draft-ietf-netconf-notification-messages-04 17 Abstract 19 This document defines a new notification message format, using yang- 20 data. Included 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 23, 2019. 50 Copyright Notice 52 Copyright (c) 2018 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 . . . . . . . . . . . . . . 5 72 4.2. Many Notifications per Message . . . . . . . . . . . . . 5 73 5. Configuration of Headers . . . . . . . . . . . . . . . . . . 8 74 6. Discovering Receiver Support . . . . . . . . . . . . . . . . 9 75 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 18 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 78 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 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 and yang 93 datastore push are being defined in 94 [I-D.draft-ietf-netconf-subscribed-notifications] and 95 [I-D.ietf-netconf-yang-push]. Work on those documents has shown that 96 notifications described in [RFC7950] section 7.16 could benefit from 97 transport independent headers. Communicating the following 98 information to receiving applications can be done without explicit 99 linkage to an underlying transport protocol: 101 o the time information was generated 103 o the time the information was placed in a message and queued for 104 transport 106 o a signature to verify authenticity 108 o the process generating the information 110 o an originating request correlation 112 o an ability to bundle information records into one a message 114 o the ability to check for message loss/reordering 116 The document describes information elements needed for the functions 117 above. It also provides YANG structures for sending messages 118 containing one or more events and/or update records 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 RFC 7950 [RFC7950]. Publisher, 129 receiver, subscription, and event occurence time are defined in 130 [I-D.draft-ietf-netconf-subscribed-notifications]. 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 time an event, datastore update, or other 142 item is recognized and recorded within the publisher. 144 o notification-id: Identifies the name of the notification, per the 145 YANG notification statement. May also provide the name of a yang- 146 data statement (whether transporting other types of messages is in 147 scope is tbd). 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 There are two types of transportable messages: one format is used 187 when there is one notification being encapsulated, and another format 188 used when there are many notifications being bundled into one 189 message. 191 A receiver which supporting this document MUST be able to handle 192 receipt of either type of message from an publisher. It is possible 193 that changes between message types can occur without any prior 194 indication. 196 4.1. One Notification per Message 198 This section will be re-instated if NETCONF WG members are not 199 comfortable with the efficiency of the solution which can encode many 200 notifications per message described below. 202 4.2. Many Notifications per Message 204 While possible in some scenarios, it often inefficient to marshal and 205 transport every notification independently. Instead, scale and 206 processing speed can be improved by placing multiple notifications 207 into one transportable bundle. 209 The format of this bundle appears in the yata-data tree below, and is 210 more completely defined in the yang module. There are three parts of 211 this bundle: 213 o a message header describing the marshaling, including information 214 such as when the marshaling occurred 216 o a list of encapsulated information 218 o an optional message footer for whole-message signing and message- 219 generator integrity verification. 221 Within the list of encapsulated notifications, there are also three 222 parts: 224 o a notification header defining what is in an encapsulated 225 notification 227 o the actual notification itself 229 o an optional notification footer for individual notification 230 signing and observation-domain integrity verification. 232 yang-data message 233 +--ro message! 234 +--ro message-header 235 | +--ro message-time yang:date-and-time 236 | +--ro message-id? uint32 237 | +--ro message-generator-id? string 238 | +--ro notification-count? uint16 239 +--ro notifications* 240 | +--ro notification-header 241 | | +--ro notification-time yang:date-and-time 242 | | +--ro yang-module? yang:yang-identifier 243 | | +--ro yang-notification-name? notification-type 244 | | +--ro subscription-id* uint32 245 | | +--ro notification-id? uint32 246 | | +--ro observation-domain-id? string 247 | +--ro notification-contents? 248 | +--ro notification-footer! 249 | +--ro signature-algorithm string 250 | +--ro signature-value string 251 | +--ro integrity-evidence? string 252 +--ro message-footer! 253 +--ro signature-algorithm string 254 +--ro signature-value string 255 +--ro integrity-evidence? string 257 An XML instance of a message might look like: 259 261 262 263 2017-02-14T00:00:05Z 264 265 266 456 267 268 269 2 270 271 272 273 274 275 276 2017-02-14T00:00:02Z 277 278 279 823472 280 281 282 ietf-yang-push 283 284 285 push-change-update 286 287 288 289 291 292 293 295 296 297 298 299 300 301 ...(record #2)... 302 303 304 306 5. Configuration of Headers 308 A publisher MUST select the set of headers to use within any 309 particular message. The two mandatory headers which MUST always be 310 applied are 'message-time' and 'subscription-id' 312 Beyond these two mandatory headers, additional headers MAY be 313 included. Configuration of what these optional headers should be can 314 come from the following sources: 316 1. Publisher wide default headers for all notifications. These are 317 included if an optional header is inserted into 'additional- 318 headers' leaf-list shown in the yang tree below. 320 2. More notification specific headers may also be desired. If new 321 headers are needed for a specific type of YANG notification, 322 these can be populated through 'additional-notification-headers' 323 leaf-list. 325 3. An application process may also identify common headers to use 326 when transporting notifications for a specific subscription. How 327 these are identified to a publisher is out-of-scope. 329 The set of headers used for any particular message is the superset of 330 headers for the items listed above. 332 The YANG tree showing elements of configuration is depicted in the 333 following figure. 335 module: ietf-notification-messages 336 +--rw additional-default-headers {publisher}? 337 +--rw additional-headers* optional-header 338 +--rw yang-notification-specific-default* 339 | [yang-module yang-notification-name] 340 +--rw yang-module yang:yang-identifier 341 +--rw yang-notification-name notification-type 342 +--rw additional-notification-headers* 343 optional-notification-header 345 Configuration Model structure 347 Of note in this tree is the optional feature of 'publisher'. This 348 feature indicates an ability to send notifications. A publisher 349 supporting this specification MUST also be able to parse any messages 350 received as defined in this document. 352 6. Discovering Receiver Support 354 We need capability exchange from the receiver to the publisher at 355 transport session initiation to indicate support for this 356 specification. 358 For all types of transport connections, if the receiver indicates 359 support for this specification, then it MAY be used. In addition, 360 [RFC5277] one-way notifications MUST NOT be used if the receiver 361 indicates support for this specification to a publisher which also 362 supports it. 364 Where NETCONF transport is used, advertising this specification's 365 namespace during an earlier client capabilities discovery phase MAY 366 be used to indicate support for this specification: 368 369 370 371 urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0 372 373 374 4 375 377 NOTE: It is understood that even though it is allowed in [RFC6241] 378 section 8.1, robust NETCONF client driven capabilities exchange is 379 not something which is common in implementation. Therefore reviewers 380 are asked to submit alternative proposals to the mailing list. 382 For RESTCONF, a mechanism for capability discovery is TBD. Proposals 383 are also welcome here. 385 The mechanism described above assumes that a capability discovery 386 phase happens before a subscription is started. This is not always 387 the case. As an example, consider HTTP2 configured subscriptions 388 from section 3.1.3 of [I-D.draft-ietf-netconf-restconf-notif], there 389 is no guarantee that a capability exchange has taken place before the 390 updates are pushed. A solution for this could be that a receiver 391 would reply "ok" and reply with the client capabilities as part of 392 the POST. (Or just use a different HTTP status code like 202 instead 393 of 200 'ok'). As such a requirement creates a new dependency for 394 [I-D.draft-ietf-netconf-restconf-notif] upon this specification, more 395 discussion is required to decide if this is a viable solution. 397 7. YANG Module 399 file "ietf-notification-messages@2018-01-31.yang" 401 module ietf-notification-messages { 402 yang-version 1.1; 403 namespace 404 "urn:ietf:params:xml:ns:yang:ietf-notification-messages"; 405 prefix nm; 407 import ietf-yang-types { prefix yang; } 408 import ietf-restconf { prefix rc; } 410 organization "IETF"; 411 contact 412 "WG Web: 413 WG List: 415 Editor: Eric Voit 416 418 Editor: Henk Birkholz 419 421 Editor: Alexander Clemm 422 424 Editor: Andy Bierman 425 427 Editor: Tim Jenkins 428 "; 430 description 431 "This module contains conceptual YANG specifications for yang-data 432 messages carrying notifications with well known header objects."; 434 revision 2018-01-31 { 435 description 436 "Initial version."; 438 reference 439 "draft-ietf-netconf-notification-messages-03"; 440 } 442 /* 443 * FEATURES 444 */ 446 feature publisher { 447 description 448 "This feature indicates that support for both publisher and 449 receiver of messages complying to the specification."; 450 } 452 /* 453 * IDENTITIES 454 */ 456 /* Identities for common headers */ 458 identity common-header { 459 description 460 "A well known header which can be included somewhere within a 461 message."; 462 } 464 identity message-time { 465 base common-header; 466 description 467 "Header information consisting of time the message headers were 468 placed generated prior to being sent to transport"; 469 } 471 identity subscription-id { 472 base common-header; 473 description 474 "Header information consisting of the identifier of the 475 subscription associated with the notification being 476 encapsulated."; 477 } 479 identity notification-count { 480 base common-header; 481 description 482 "Header information consisting of the quantity of notifications in 483 a bundled-message for a specific receiver."; 484 } 486 identity optional-header { 487 base common-header; 488 description 489 "A well known header which an application may choose to include 490 within a message."; 491 } 492 identity message-id { 493 base optional-header; 494 description 495 "Header information that identifies a message to a specific 496 receiver"; 497 } 499 identity message-generator-id { 500 base optional-header; 501 description 502 "Header information consisting of an identifier for a software 503 entity which created the message (e.g., linecard 1)."; 504 } 506 identity message-signature { 507 base optional-header; 508 description 509 "Identifies two elements of header information consisting of a 510 signature and the signtature type for the contents of a message. 511 Signatures can be useful for originating applications to 512 verify record contents even when shipping over unsecure 513 transport."; 514 } 516 identity message-integrity-evidence { 517 base optional-header; 518 description 519 "Header information consisting of the information which backs up 520 the assertions made as to the validity of the information 521 provided within the message."; 522 } 524 identity optional-notification-header { 525 base optional-header; 526 description 527 "A well known header which an application may choose to include 528 within a message."; 529 } 531 identity notification-time { 532 base optional-notification-header; 533 description 534 "Header information consisting of the time an originating process 535 created the notification."; 536 } 538 identity notification-id { 539 base optional-notification-header; 540 description 541 "Header information consisting of an identifier for an instance 542 of a notification egressing a publisher. "; 543 } 545 identity observation-domain-id { 546 base optional-notification-header; 547 description 548 "Header information identifying the software entity which created 549 the notification (e.g., process id)."; 550 } 552 identity notification-signature { 553 base optional-notification-header; 554 description 555 "Header information consisting of the information which backs up 556 the assertions made as to the validity of the information 557 provided within the notification."; 558 } 560 identity notification-integrity-evidence { 561 base optional-notification-header; 562 description 563 "Header information consisting of the information which backs up 564 the assertions made as to the validity of the information 565 provided within the notification."; 566 } 568 /* 569 * TYPEDEFs 570 */ 572 typedef optional-header { 573 type identityref { 574 base optional-header; 575 } 576 description 577 "Type of header object which may be included somewhere within a 578 message."; 579 } 581 typedef optional-notification-header { 582 type identityref { 583 base optional-notification-header; 584 } 585 description 586 "Type of header object which may be included somewhere within a 587 message."; 588 } 590 typedef notification-type { 591 type string { 592 pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*'; 593 } 594 description 595 "The name of a notification within a YANG module."; 596 reference 597 "RFC-7950 Section 7.16"; 598 } 600 /* 601 * GROUPINGS 602 */ 604 grouping message-header { 605 description 606 "Header information included with a message."; 607 leaf message-time { 608 type yang:date-and-time; 609 mandatory true; 610 description 611 "time the message was generated prior to being sent to 612 transport."; 613 } 614 leaf message-id { 615 type uint32; 616 description 617 "Id for a message going to a receiver from a message 618 generator. The id will increment by one with each message sent 619 from a particular message generator, allowing the message-id 620 to be used as a sequence number."; 621 } 622 leaf message-generator-id { 623 type string; 624 description 625 "Software entity which created the message (e.g., linecard 1). 626 The combination of message-id and message-generator-id must be 627 unique until reset or a roll-over occurs."; 628 } 629 leaf notification-count { 630 type uint16; 631 description 632 "Quantity of notification records in a bundled-message 633 specific receiver."; 634 } 635 } 637 grouping notification-within-a-module { 638 description 639 "A location of a notification within a yang model."; 640 leaf yang-module { 641 type yang:yang-identifier; 642 description 643 "Name of the YANG module supported by the publisher."; 644 } 645 leaf yang-notification-name { 646 type notification-type; 647 description 648 "The name of a notification likely from a YANG module. Note 649 that this object should be in the notification contents, so a 650 debate is needed whether this is redundant."; 651 } 652 } 654 grouping notification-header { 655 description 656 "Common informational objects which might help a receiver 657 interpret the meaning, details, or importance of a notification."; 658 leaf notification-time { 659 type yang:date-and-time; 660 mandatory true; 661 description 662 "Time the system recognized the occurrence of an event."; 663 } 664 uses notification-within-a-module; 665 leaf-list subscription-id { 666 type uint32; 667 description 668 "Id of the subscription which led to the notification being 669 generated."; 670 } 671 leaf notification-id { 672 type uint32; 673 description 674 "Identifier for the notification record."; 675 } 676 leaf observation-domain-id { 677 type string; 678 description 679 "Software entity which created the notification record (e.g., 680 process id)."; 682 } 683 } 685 grouping security-footer { 686 description 687 "Reusable grouping for common objects which apply to the the 688 signing of notifications or messages."; 689 leaf signature-algorithm { 690 type string; 691 mandatory true; 692 description 693 "The technology with which an originator signed of some 694 delineated contents."; 695 } 696 leaf signature-value { 697 type string; 698 mandatory true; 699 description 700 "Any originator signing of the contents of a header and 701 content. This is useful for verifying contents even when 702 shipping over unsecure transport."; 703 } 704 leaf integrity-evidence { 705 type string; 706 description 707 "This mechanism allows a verifier to ensure that the use of the 708 private key, represented by the corresponding public key 709 certificate, was performed with a TCG compliant TPM 710 environment. This evidence is never included in within any 711 signature."; 712 reference 713 "TCG Infrastructure Workgroup, Subject Key Attestation Evidence 714 Extension, Specification Version 1.0, Revision 7."; 715 } 716 } 718 /* 719 * YANG-DATA messages for receivers 720 */ 722 rc:yang-data message { 723 container message { 724 presence 725 "Indicates attempt to communicate notifications to a receiver."; 726 description 727 "Message to a receiver containing one or more notifications"; 729 container message-header { 730 description 731 "Header info for messages."; 732 uses message-header; 733 } 734 list notifications { 735 description 736 "Set of notifications to a receiver."; 737 container notification-header { 738 description 739 "Header info for a notification."; 740 uses notification-header; 741 } 742 anydata notification-contents { 743 description 744 "Encapsulates objects following YANG's notification-stmt 745 grammar of RFC-7950 section 14. Within are the notified 746 objects the publisher actually generated in order to be 747 passed to a receiver after all filtering has completed."; 748 } 749 container notification-footer { 750 presence 751 "Indicates attempt to secure a notification."; 752 description 753 "Signature and evidence for messages."; 754 uses security-footer; 755 } 756 } 757 container message-footer { 758 presence 759 "Indicates attempt to secure the entire message."; 760 description 761 "Signature and evidence for messages."; 762 uses security-footer; 763 } 764 } 765 } 767 /* 768 * DATA-NODES 769 */ 771 container additional-default-headers { 772 if-feature "publisher"; 773 description 774 "This container maintains a list of which additional notifications 775 should use which optional headers if the receiver supports this 776 specification."; 778 leaf-list additional-headers { 779 type optional-header; 780 description 781 "This list contains the identities of the optional header types 782 which are to be included within each message from this 783 publisher."; 784 } 785 list yang-notification-specific-default { 786 key "yang-module yang-notification-name"; 787 description 788 "For any included YANG notifications, this list provides 789 additional optional headers which should be placed within the 790 container notification-header if the receiver supports this 791 specification. This list incrementally adds to any headers 792 indicated within the leaf-list 'additional-headers'."; 793 uses notification-within-a-module; 794 leaf-list additional-notification-headers { 795 type optional-notification-header; 796 description 797 "The set of additional default headers which will be sent 798 for a specific YANG notification."; 799 } 800 } 801 } 802 } 804 806 8. Backwards Compatibility 808 With this specification, there is no change to YANG's 'notification' 809 statement 811 Legacy clients are unaffected, and existing users of [RFC5277], 812 [RFC7950], and [RFC8040] are free to use current behaviors until all 813 involved device support this specification. 815 9. Security Considerations 817 Certain headers might be computationally complex for a publisher to 818 deliver. Signatures or encryption are two examples of this. It MUST 819 be possible to suspend or terminate a subscription due to lack of 820 resources based on this reason. 822 Decisions on whether to bundle or not to a receiver are fully under 823 the purview of the Publisher. A receiver could slow delivery to 824 existing subscriptions by creating new ones. (Which would result in 825 the publisher going into a bundling mode.) 827 10. Acknowledgments 829 For their valuable comments, discussions, and feedback, we wish to 830 acknowledge Martin Bjorklund, Einar Nilsen-Nygaard, and Kent Watsen. 832 11. References 834 11.1. Normative References 836 [I-D.draft-ietf-netconf-subscribed-notifications] 837 Voit, E., Clemm, A., Gonzalez Prieto, A., Tripathy, A., 838 and E. Nilsen-Nygaard, "Custom Subscription to Event 839 Streams", draft-ietf-netconf-subscribed-notifications-16 840 (work in progress), August 2018. 842 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 843 Requirement Levels", BCP 14, RFC 2119, 844 DOI 10.17487/RFC2119, March 1997, 845 . 847 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 848 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, 849 . 851 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 852 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 853 May 2017, . 855 11.2. Informative References 857 [I-D.draft-ietf-netconf-restconf-notif] 858 Voit, Eric., Clemm, Alexander., Tripathy, A., Nilsen- 859 Nygaard, E., and Alberto. Gonzalez Prieto, "Restconf and 860 HTTP transport for event notifications", June 2018, 861 . 864 [I-D.ietf-netconf-yang-push] 865 Clemm, Alexander., Voit, Eric., Gonzalez Prieto, Alberto., 866 Tripathy, A., Nilsen-Nygaard, E., Bierman, A., and B. 867 Lengyel, "YANG Datastore Subscription", August 2018, 868 . 871 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 872 and A. Bierman, Ed., "Network Configuration Protocol 873 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 874 . 876 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 877 RFC 7950, DOI 10.17487/RFC7950, August 2016, 878 . 880 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 881 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 882 . 884 Appendix A. Changes between revisions 886 (To be removed by RFC editor prior to publication) 888 v03 - v04 890 o Terminology tweaks. 892 o Revision before expiration. Awaiting closure of SN prior to 893 update. 895 v02 - v03 897 o Removed the option for an unbundled message. This might be re- 898 added later for transport efficiency if desired by the WG 900 o New message structure driven by the desire to put the signature 901 information at the end. 903 v01 - v02 905 o Fixed the yang-data encapsulation container issue 907 o Updated object definitions to point to RFC-7950 definitions 909 o Added headers for module and notification-type. 911 v00 - v01 913 o Alternative to 5277 one-way notification added 915 o Storage of default headers by notification type 917 o Backwards compatibility 919 o Capability discovery 921 o Move to yang-data 922 o Removed dscp and record-type as common headers. (Record type can 923 be determined by the namespace of the record contents. Dscp is 924 useful where applications need internal communications within a 925 Publisher, but it is unclear as to whether this use case need be 926 exposed to a receiver. 928 Appendix B. Issues being worked 930 (To be removed by RFC editor prior to publication) 932 Is this capability just for notifications, or is it for any yang-data 933 element too? 935 A complete JSON document is supposed to be sent as part of Media Type 936 "application/yang-data+json". As we are sending separate 937 notifications after each other, we need to choose whether we start 938 with some extra encapsulation for the very first message pushed, or 939 if we want a new Media Type for streaming updates. 941 Improved discovery mechanisms for NETCONF 943 Should we defer support for HTTP2 configured subscriptions until this 944 draft is available? Without capabilities exchange, it might just be 945 easier to wait. In addition, JSON encoding still needs a 946 notification type which is not exising or represented in 947 referenceable in existing yang-models. 949 Need to ensure the proper references exist to a notification 950 definition driven by RFC-7950 which is acceptable to other eventual 951 users of this specification. 953 We need to link to Andy Bierman's anydata extensibility draft for 954 informational purposes. This is under a WG adoption call. 956 Appendix C. Subscription Specific Headers 958 (To be removed by RFC editor prior to publication) 960 This section discusses a future functional addition which could 961 leverage this draft. It is included for informational purposes only. 963 A dynamic subscriber might want to mandate that certain headers be 964 used for push updates from a publisher. Some examples of this 965 include a subscriber requesting to: 967 o establish this subscription, but just if transport messages 968 containing the pushed data will be encrypted, 970 o establish this subscription, but only if you can attest to the 971 information being delivered in requested notification records, or 973 o provide a sequence-id for all messages to this receiver (in order 974 to check for loss). 976 Providing this type of functionality would necessitate a new revision 977 of the [I-D.draft-ietf-netconf-subscribed-notifications]'s RPCs and 978 state change notifications. Subscription specific header information 979 would overwrite the default headers identified in this document. 981 Appendix D. Implications to Existing RFCs 983 (To be removed by RFC editor prior to publication) 985 YANG one-way exchanges currently use a non-extensible header and 986 encoding defined in section 4 of RFC-5277. These RFCs MUST be 987 updated to enable this draft. These RFCs SHOULD be updated to 988 provide examples 990 D.1. Implications to RFC-7950 992 Sections which expose netconf:capability:notification:1.0 are 4.2.10 994 Sections which provide examples using netconf:notification:1.0 are 995 7.10.4, 7.16.3, and 9.9.6 997 D.2. Implications to RFC-8040 999 Section 6.4 demands use of RFC-5277's netconf:notification:1.0, and 1000 later in the section provides an example. 1002 Authors' Addresses 1004 Eric Voit 1005 Cisco Systems 1007 Email: evoit@cisco.com 1009 Henk Birkholz 1010 Fraunhofer SIT 1012 Email: henk.birkholz@sit.fraunhofer.de 1013 Andy Bierman 1014 YumaWorks 1016 Email: andy@yumaworks.com 1018 Alexander Clemm 1019 Huawei 1021 Email: ludwig@clemm.org 1023 Tim Jenkins 1024 Cisco Systems 1026 Email: timjenki@cisco.com