idnits 2.17.1 draft-ietf-netconf-notification-capabilities-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 4, 2019) is 1668 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) == Missing Reference: 'RFC8341' is mentioned on line 532, but not defined == Outdated reference: A later version (-21) exists of draft-ietf-netmod-yang-instance-file-format-04 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF B. Lengyel 3 Internet-Draft Ericsson 4 Intended status: Standards Track A. Clemm 5 Expires: March 7, 2020 Futurewei 6 B. Claise 7 Cisco Systems, Inc. 8 September 4, 2019 10 Yang-Push Notification Capabilities 11 draft-ietf-netconf-notification-capabilities-04 13 Abstract 15 This document proposes a YANG module that allows a server to specify 16 server capabilities related to "Subscription to YANG Datastores" 17 (Yang-Push). It proposes to use YANG Instance Data to document this 18 information and make it already available at implementation time, but 19 also allow it to be reported at run-time. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 7, 2020. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Notification Capability Model . . . . . . . . . . . . . . . . 4 58 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 5 59 3.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 6 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 62 5.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 12 63 5.2. The YANG Module Names Registry . . . . . . . . . . . . . 12 64 6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 67 7.2. Informative References . . . . . . . . . . . . . . . . . 13 68 Appendix A. Instance data examples . . . . . . . . . . . . . . . 14 69 Appendix B. Changes between revisions . . . . . . . . . . . . . 17 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 72 1. Terminology 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 76 "OPTIONAL" in this document are to be interpreted as described in BCP 77 14 [RFC2119] [RFC8174] when, and only when, they appear in all 78 capitals, as shown here. 80 The terms Yang-Push, On-change subscription and Periodic subscription 81 are used as defined in [I-D.ietf-netconf-yang-push] 83 On-change Notification Capability: The capability of the server to 84 support On-change subscriptions. 86 The term Server is used as defined in [RFC8342] 88 Implementation-time information: Information about the server's 89 behavior that is made available during the implementation of the 90 server, available from a source other then a running server. 92 Run-time information: Information about the server's behavior that is 93 available from the running server via management protocols such as 94 NETCONF [RFC6241] or RESTCONF [RFC8040]. 96 2. Introduction 98 As defined in [I-D.ietf-netconf-yang-push] a server may allow clients 99 to subscribe to updates from a datastore and subsequently push such 100 update notifications to the client. Notifications may be sent 101 periodically or on-change (more or less immediately after each 102 change). 104 A server supporting YANG-Push has a number of capabilities defined in 105 [I-D.ietf-netconf-yang-push] that are often determined during the 106 implementation of the server. These include: 108 o Supported (reporting) periods for periodic subscriptions 110 o Maximum number of objects that can be sent in an update 112 If the optional on-change feature is supported, additionally: 114 o Supported dampening periods for on-change subscriptions 116 o The set of data nodes for which on-change notification is 117 supported 119 Servers MAY have limitations in how many update notifications and how 120 many datastore node updates they can send out in a certain time- 121 period. 123 In some cases, a publisher supporting on-change notifications will 124 not be able to push updates for some object types on-change. Reasons 125 for this might be that the value of the datastore node changes 126 frequently (e.g. in-octets counter), that small object changes are 127 frequent and meaningless (e.g., a temperature gauge changing 0.1 128 degrees), or that the implementation is not capable of on-change 129 notification for a particular object. In those cases, it will be 130 important for client applications to have a way to identify for which 131 objects on-change notifications are supported and for which ones not. 133 Faced with the reality that support for on-change notification does 134 not mean that such notifications will be sent for any specific data 135 node, client/management applications can not rely on the on-change 136 functionality unless the client has some means to identify for which 137 objects on-change notifications are supported. YANG models are meant 138 to be used as an interface contract. Without identification of the 139 data nodes actually supporting on-change, this contract would be 140 incomplete. 142 This document proposes a YANG module that allows a client to discover 143 YANG-Push related capabilities both at implementation-time and run- 144 time. 146 Implementation time information is needed by Network Management 147 System (NMS) implementers. During NMS implementation for any 148 functionality that depends on the notifications the information about 149 on change notification capability is needed. If the information is 150 not available early in some document, but only as instance data from 151 the network node once it is deployed, the NMS implementation will be 152 delayed, because it has to wait for the network node to be ready. In 153 addition, the assumption that all NMS implementers will have a 154 correctly configured network node available to retrieve data from, is 155 an expensive proposition and may not always hold. (An NMS may need 156 to be able to handle many dozens of network node types.) Often a 157 fully functional NMS is a requirement for introducing a new network 158 node type into a network, so delaying NMS readiness effectively also 159 delays the time at which a new network node type can be introduced 160 into the network. 162 Implementation time information is needed by system integrators. 163 When introducing a network node type into their network, operators 164 often need to integrate the node type into their own management 165 system. The NMS may have management functions that depend on on- 166 change notifications. The network operator needs to plan his 167 management practices and NMS implementation before he even decides to 168 buy the specific network node type. Moreover the decision to buy the 169 node type sometimes depends on these management possibilities. 171 Run-time information is needed: 173 o for any "purely model driven" client, e.g. a NETCONF-browser. As 174 long as it has a valid model to read the capability information, 175 it does not care which data nodes send notification, it will just 176 handle what is available. 178 o in case the capability might change during run-time e.g. due to 179 licensing, HW constraints etc. 181 o to check that early, implementation time capability information 182 about the capabilities is indeed what the server implements (is 183 the supplied documentation correct?) 185 3. Notification Capability Model 187 It is a goal to provide Yang-Push notification capability information 188 in a format that is: 190 o vendor independent 192 o formal 194 o identical for implementation-time and run-time 196 The YANG module ietf-notification-capabilities is defined to provide 197 the information. It contains: 199 a set of capabilities related to the amount of notifications the 200 server can send out 202 specification of which data nodes support on-change notifications. 204 Capability values can be specified on server level, datastore 205 level or on specific data nodes (and their contained sub-tree) of 206 a specific datastore. Capability values on a smaller, more 207 specific part of the server's data always override more generic 208 values. 210 On-change capability is not specified on a server level as 211 different datastores usually have different on-change 212 capabilities. On a datastore level on-change capability for 213 configuration and state data can be specified separately. 215 The information SHALL be provided in two ways both following the 216 ietf-notification-capabilities module: 218 o For the implementation-time use-case: It SHALL be provided by the 219 implementer as YANG instance data file complying to 220 [I-D.ietf-netmod-yang-instance-file-format]. The file SHALL be 221 available already in implementation time retrievable in a way that 222 does not depend on a live network node. E.g. download from 223 product Website. 225 o For the run-time use-case: It SHALL be available via NETCONF 226 [RFC6241] or RESTCONF [RFC8040] from the live server during run- 227 time. Implementations which support changing these capabilities 228 at run-time SHOULD support on-change notifications about the 229 datastore-subscription-capabilities container. 231 3.1. Tree Diagram 233 The following tree diagram [RFC8340] provides an overview of the data 234 model. 236 module: ietf-notification-capabilities 237 +--ro datastore-subscription-capabilities 238 +--ro (update-period)? 239 | +--:(minimum-update-period) 240 | | +--ro minimum-update-period? uint32 241 | +--:(supported-update-period) 242 | +--ro supported-update-period* uint32 243 +--ro max-objects-per-update? uint32 244 +--ro minimum-dampening-period? uint32 {yp:on-change}? 245 +--ro datastore-capabilities* [datastore] 246 +--ro datastore union 247 +--ro (update-period)? 248 | +--:(minimum-update-period) 249 | | +--ro minimum-update-period? uint32 250 | +--:(supported-update-period) 251 | +--ro supported-update-period* uint32 252 +--ro max-objects-per-update? uint32 253 +--ro minimum-dampening-period? uint32 {yp:on-change}? 254 +--ro on-change-supported-for-config? boolean {yp:on-change}? 255 +--ro on-change-supported-for-state? boolean {yp:on-change}? 256 +--ro per-node-capabilities* [node-selector] 257 +--ro node-selector nacm:node-instance-identifier 258 +--ro (update-period)? 259 | +--:(minimum-update-period) 260 | | +--ro minimum-update-period? uint32 261 | +--:(supported-update-period) 262 | +--ro supported-update-period* uint32 263 +--ro max-objects-per-update? uint32 264 +--ro minimum-dampening-period? uint32 {yp:on-change}? 265 +--ro on-change-supported boolean {yp:on-change}? 267 3.2. YANG Module 269 file "ietf-notification-capabilities@2019-08-13.yang" 271 module ietf-notification-capabilities { 272 yang-version 1.1; 273 namespace 274 "urn:ietf:params:xml:ns:yang:ietf-notification-capabilities"; 275 prefix inc; 277 import ietf-netconf-acm { prefix nacm; } 278 import ietf-yang-push { prefix yp; } 279 import ietf-yang-library { 280 prefix yanglib; 281 description 282 "Requires revision 2019-01-04 or a revision derived from it."; 283 } 284 organization 285 "IETF NETCONF (Network Configuration) Working Group"; 286 contact 287 "WG Web: 288 WG List: 290 Editor: Balazs Lengyel 291 "; 292 description 293 "This module specifies YANG-Push related server 294 capabilities. 296 The module contains 297 - capabilities related to the amount of notifications the 298 server can send out. (Note that for a specific subscription 299 the server MAY still allow only longer periods or smaller 300 updates depending on e.g. actual load conditions.) 301 - specification of which data nodes support on-change 302 notifications. 304 Capability values on a 305 smaller, more specific part of the server's data always override 306 more generic values. The hierarchy of specifications from generic 307 to more specific is: 308 1) top level values valid for all datastores 309 2) values for a specific datastore (including the special 310 'all' datastore identifier) 311 3) Value for a specific data node and its contained sub-tree 312 in one of the datastores. Such capability values are inherited 313 down the containment tree unless a more specific value is 314 provided, as described in 4) 315 4) A contained, smaller, more specific sub-tree in a specific 316 datastore (could be a single leaf) 318 Any capability value MAY be absent if a more generic capability 319 value is already provided or if the server is not capable of 320 providing a value. 322 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 323 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 324 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 325 are to be interpreted as described in BCP 14 (RFC 2119) 326 (RFC 8174) when, and only when, they appear in all 327 capitals, as shown here. 329 Copyright (c) 2019 IETF Trust and the persons identified as 330 authors of the code. All rights reserved. 332 Redistribution and use in source and binary forms, with or 333 without modification, is permitted pursuant to, and subject 334 to the license terms contained in, the Simplified BSD License 335 set forth in Section 4.c of the IETF Trust's Legal Provisions 336 Relating to IETF Documents 337 (http://trustee.ietf.org/license-info). 339 This version of this YANG module is part of RFC XXXX; see 340 the RFC itself for full legal notices."; 342 revision 2019-08-13 { 343 description 344 "Initial version"; 345 reference 346 "RFC XXX: Yang-Push Notification Capabilities"; 347 } 349 container datastore-subscription-capabilities { 350 config false; 351 description 352 "YANG-Push related server capabilities"; 354 grouping datastore-subscription-throughput-capabilities { 355 description "Capability values that affect the amount of 356 notifications the server can send out."; 358 choice update-period { 359 description 360 "Supported update-period values."; 361 leaf minimum-update-period { 362 type uint32; 363 units "centiseconds"; 364 description 365 "Minimum update period supported for a 366 periodic subscription."; 367 } 369 leaf-list supported-update-period { 370 type uint32; 371 units "centiseconds"; 372 description "Supported update period values for a 373 periodic subscription (used if only these specific 374 values are supported)."; 375 } 376 } 378 leaf max-objects-per-update { 379 type uint32 { 380 range "1..max"; 381 } 382 description 383 "Maximum number of objects that can be sent 384 in an update."; 385 } 387 leaf minimum-dampening-period { 388 if-feature yp:on-change ; 389 type uint32; 390 units "centiseconds"; 391 description 392 "The minimum dampening period supported for on-change 393 subscriptions."; 394 } 395 } 397 uses datastore-subscription-throughput-capabilities { 398 description "Top level throughput capabilities. 399 These values can be overridden by values provided per 400 datastore or for individual data nodes in a datastore."; 401 } 403 list datastore-capabilities { 404 key datastore ; 405 description "Capabilities values per datastore. 406 For non-NMDA servers the config=false data is considered 407 as if it was part of the running datastore. 409 Indicates per datastore throughput capabilities. 411 Indicates per datastore the data nodes for which the 412 server is capable of sending on-change notifications. 413 If a datastore implemented by the server is not specified 414 in this list and there is no list element for 'all' datastores 415 the datastore does not support any on-change notifications. 417 On-change notifications SHALL be sent for a config=true 418 data node if one of the following is true: 419 - if it is a top level data-node and is not specified in the 420 per-node-capabilities list and on-change-supported-for-config 421 is true; or 422 - notifications are sent for its parent data node and it is 423 not specified in the per-node-capabilities list; or 424 - it is specified in the per-node-capabilities list and has 425 an on-change-supported value true. 427 On-change notifications SHALL be sent for a config=false 428 data node if one of the following is true: 429 - if it is a top level data-node (a config=false data node with 430 a config=true parent SHALL be treated as a top level data node) 431 and is not specified in the per-node-capabilities list and 432 on-change-supported-for-state is true; or 433 - notifications are sent for its parent data node 434 which is also config=false and it is not specified in the 435 per-node-capabilities list; or 436 - it is specified in the per-node-capabilities list and has 437 an on-change-supported value true"; 439 leaf datastore { 440 type union { 441 type leafref { 442 path /yanglib:yang-library/yanglib:datastore/yanglib:name ; 443 } 444 type enumeration { 445 enum all ; 446 } 447 } 448 must '. != "all" or count(..) = "1" ' { 449 error-message 450 "If 'all' is present individual datastores cannot be " + 451 "specified."; 452 } 453 description "The datastore for which capabilities are defined."; 454 } 456 uses datastore-subscription-throughput-capabilities { 457 description "Throughput capabilities for a datastore. 458 These values will override top level values and can be 459 overridden by values provided for individual data nodes 460 in a datastore."; 461 } 463 leaf on-change-supported-for-config { 464 if-feature yp:on-change ; 465 type boolean; 466 default "true"; 467 description 468 "Specifies the default value for 469 top level config=true data nodes for the 470 on-change-supported capability."; 471 } 473 leaf on-change-supported-for-state { 474 if-feature yp:on-change ; 475 type boolean; 476 default "false"; 477 description 478 "Specifies the default value for 479 top level config=false data nodes for the 480 on-change-supported capability."; 481 } 483 list per-node-capabilities { 484 key "node-selector"; 485 description 486 "A list of data nodes that have either a throughput or 487 on-change-notification capability specifically defined. 489 Should be used only when specific data nodes support 490 capabilities that are different from capabilities 491 of their parent nodes or the default for the datastore."; 493 leaf node-selector { 494 type nacm:node-instance-identifier; 495 description 496 "Selects the data nodes for which 497 a capability is specified."; 498 } 500 uses datastore-subscription-throughput-capabilities { 501 description "Throughput capabilities for a specific data node. 502 These values will override top level or datastore 503 specific values."; 504 } 506 leaf on-change-supported { 507 if-feature yp:on-change ; 508 type boolean; 509 mandatory true; 510 description 511 "Specifies whether the server is capable of 512 sending on-change notifications for the selected 513 data nodes."; 514 } 515 } 516 } 517 } 518 } 520 522 4. Security Considerations 524 The YANG module specified in this document defines a schema for data 525 that is designed to be accessed via network management protocols such 526 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 527 is the secure transport layer, and the mandatory-to-implement secure 528 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 529 is HTTPS, and the mandatory-to-implement secure transport is TLS 530 [RFC8446]. 532 The Network Configuration Access Control Model (NACM) [RFC8341] 533 provides the means to restrict access for particular NETCONF or 534 RESTCONF users to a preconfigured subset of all available NETCONF or 535 RESTCONF protocol operations and content. 537 The data in this module is not security sensitive. 539 5. IANA Considerations 541 5.1. The IETF XML Registry 543 This document registers one URI in the IETF XML registry [RFC3688]. 544 Following the format in [RFC3688], the following registrations are 545 requested: 547 URI: urn:ietf:params:xml:ns:yang:ietf-notification-capabilities 548 Registrant Contact: The NETCONF WG of the IETF. 549 XML: N/A, the requested URI is an XML namespace. 551 5.2. The YANG Module Names Registry 553 This document registers one YANG module in the YANG Module Names 554 registry [RFC7950]. Following the format in [RFC7950], the the 555 following registrations are requested: 557 name: ietf-notification-capabilities 558 namespace: urn:ietf:params:xml:ns:yang:ietf-notification-capabilities 559 prefix: inc 560 reference: RFC XXXX 562 6. Open Issues 564 - 566 7. References 568 7.1. Normative References 570 [I-D.ietf-netconf-yang-push] 571 Clemm, A. and E. Voit, "Subscription to YANG Datastores", 572 draft-ietf-netconf-yang-push-25 (work in progress), May 573 2019. 575 [I-D.ietf-netmod-yang-instance-file-format] 576 Lengyel, B. and B. Claise, "YANG Instance Data File 577 Format", draft-ietf-netmod-yang-instance-file-format-04 578 (work in progress), August 2019. 580 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 581 and A. Bierman, Ed., "Network Configuration Protocol 582 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 583 . 585 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 586 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 587 . 589 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 590 RFC 7950, DOI 10.17487/RFC7950, August 2016, 591 . 593 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 594 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 595 . 597 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 598 and R. Wilton, "Network Management Datastore Architecture 599 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 600 . 602 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 603 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 604 . 606 7.2. Informative References 608 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 609 Requirement Levels", BCP 14, RFC 2119, 610 DOI 10.17487/RFC2119, March 1997, 611 . 613 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 614 DOI 10.17487/RFC3688, January 2004, 615 . 617 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 618 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 619 May 2017, . 621 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 622 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 623 . 625 Appendix A. Instance data examples 627 The following example is instance-data describing the notification 628 capabilities of a hypothetical "acme-switch". The switch implements 629 the running, candidate and operational datastores. Every change can 630 be reported on-change from running, nothing from candidate and all 631 config=false data from operational. 633 634 636 acme-switch-notification-capabilities 637 ietf-notification-capabilities@2019-08-13.yang 638 639 Notification capabilities of acme-switch. 640 Acme-switch implements the running, candidate and operational 641 datastores. Every change can be reported on-change from running, 642 nothing from candidate and all config=false data from operational. 643 644 645 646 500 647 2000 648 100 649 650 651 running 652 653 656 657 659 660 661 operational 662 663 664 false 665 666 667 true 668 669 670 671 672 674 Figure 1: Notification Capabilities with default settings 676 The following is the instance-data describing the notification 677 capabilities of a hypothetical "acme-router". The router implements 678 the running, and operational datastores. Every change can be 679 reported on-change from running, but only config=true nodes and some 680 config=false data from operational. Interface statistics are not 681 reported on-change only 2 important counters. Datastore subscription 682 capabilities are not reported on-change as they never change on the 683 acme-router during run-time. 685 686 688 acme-router-notification-capabilities 689 ietf-notification-capabilities@2019-08-13.yang 690 691 Defines the notification capabilities of an acme-router. 692 The router only has running, and operational datastores. 693 Every change can be reported on-change from running, but 694 only config=true nodes and some config=false data from operational. 695 Statistics are not reported on-change only 2 important counters, 696 for these a smaller dampening period is possible. 697 698 699 701 500 702 2000 703 100 704 705 706 running 707 708 709 710 711 operational 712 713 714 true 715 716 717 718 /inc:datastore-subscription-capabilities 719 false 720 721 722 723 /if:interfaces/if:interface/if:statistics 724 false 725 726 727 728 /if:interfaces/if:interface/if:statistics/if:in-octets 730 731 10 732 true 733 734 735 736 /if:interfaces/if:interface/if:statistics/if:out-octets 737 738 true 739 10 740 741 742 743 744 746 Figure 2: Notification Capabilities with data node specific settings 748 Appendix B. Changes between revisions 750 v03 - v04 752 o Clarified recommended support for on-change notifications about 753 the datastore-subscription-capabilities. 755 v02 - v03 757 o Allow throughput related capabilities to be defined on top, 758 datastore or data node level. Described that specific capability 759 values always override generic ones. 761 o Indicate that non-NMDA servers can also use this model. 763 o Updated according to draft-ietf-netmod-yang-instance-file- 764 format-04 766 v01 - v02 768 o Added instance data examples 770 o On-change capability can be defined per datastore 772 o Added "if-feature yp:on-change" where relevant 774 o Unified units used 776 v00 - v01 777 o Add more capabilities: minimum period, supported period max-number 778 of objects, min dampening period, dampening supported 780 Authors' Addresses 782 Balazs Lengyel 783 Ericsson 784 Magyar Tudosok korutja 11 785 1117 Budapest 786 Hungary 788 Email: balazs.lengyel@ericsson.com 790 Alexander Clemm 791 Futurewei 792 2330 Central Expressway 793 Santa Clara, CA 95050 794 USA 796 Email: ludwig@clemm.org 798 Benoit Claise 799 Cisco Systems, Inc. 800 De Kleetlaan 6a b1 801 1831 Diegem 802 Belgium 804 Email: bclaise@cisco.com