idnits 2.17.00 (12 Aug 2021) /tmp/idnits63775/draft-wu-netmod-base-notification-nmda-03.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 21 characters in excess of 72. ** The abstract seems to contain references ([RFC8342]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 218 has weird spacing: '...eration enu...' -- The document date (June 29, 2019) is 1050 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: 'RFC8040' is mentioned on line 79, but not defined == Missing Reference: 'RFC8174' is mentioned on line 113, but not defined == Missing Reference: 'RFC8340' is mentioned on line 203, but not defined == Missing Reference: 'RFC7950' is mentioned on line 609, but not defined == Unused Reference: 'RFC6020' is defined on line 651, but no explicit reference was found in the text == Unused Reference: 'RFC8072' is defined on line 673, but no explicit reference was found in the text == Outdated reference: draft-ietf-netmod-nmda-diff has been published as RFC 9144 ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991) Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD Working Group Q. Wu 3 Internet-Draft R. Tao 4 Intended status: Standards Track R. Ranade 5 Expires: December 31, 2019 Huawei 6 June 29, 2019 8 NMDA Base Notification for Intent based configuration update 9 draft-wu-netmod-base-notification-nmda-03 11 Abstract 13 The Network Configuration Protocol (NETCONF)and RESTCONF provides 14 mechanisms to manipulate configuration datastores. NMDA introduces 15 additional datastores for systems that support more advanced 16 processing chains converting configuration to operational state. 17 However, client applications are not able to be aware of common 18 events in these additional datstores of the management system, such 19 as a intended configuration state change in NETCONF server or 20 RESTCONF server, that may impact management applications,especially 21 when a server is managed by multiple clients or management 22 applications. This document define a YANG module that allows a 23 client to receive additional notifications for some common system 24 events pertaining to the Network Management Datastore Architecture 25 (NMDA) defined in [RFC8342]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 31, 2019. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. NMDA Base Notifications for Intent based configuration Update 3 64 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2.2. Data Model Design . . . . . . . . . . . . . . . . . . . . 5 66 2.3. Relation with NMDA Datastore Compare . . . . . . . . . . 6 67 2.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 68 3. Security Considerations . . . . . . . . . . . . . . . . . . . 13 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 71 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 72 7. Normative References . . . . . . . . . . . . . . . . . . . . 14 73 Appendix A. Changes between revisions . . . . . . . . . . . . . 15 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 76 1. Introduction 78 The Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF 79 [RFC8040] provides mechanisms to manipulate configuration datastores. 80 NMDA introduces additional datastores (e.g.,, 81 ) for systems that support more advanced processing 82 chains converting configuration to operational state. However, 83 client applications are not able to be aware of common events in 84 those additional datastores of the management system, e.g., there are 85 many background system activities (e.g.,system internal interactions 86 with hardware, interaction with protocols or other devices) that 87 happen during propagation of a configuration change to the software 88 and hardware components of a system. It is possible that some 89 configuration could not be applied to due to either 90 remnant Configuration, or missing resource, etc. There is a need for 91 user or an application (configuration) to know the origin of failed 92 configuration node and the reason why the configuration changes were 93 not applied. 95 This document define a YANG module that allows a client to receive 96 additional notifications for some common system events pertaining to 97 the Network Management Datastore Architecture (NMDA) defined in 98 [RFC8342]. These notifications are designed to support the 99 monitoring of the base system events within the server and not 100 specific to any network management protocols such as NETCONF and 101 RESTCONF. 103 The solution presented in this document is backwards compatible with 104 [RFC6470]. 106 1.1. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in BCP 111 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 The following terms are defined in [RFC8342] and are not redefined 115 here: 117 o operational state datastore 119 o running configuration datastore 121 o intended configuration datastore 123 2. NMDA Base Notifications for Intent based configuration Update 125 2.1. Overview 127 The YANG module in NETCONF Base Notifications [RFC6470] specifies the 128 following 5 event notifications for the 'NETCONF' stream to notify a 129 client application that the NETCONF server state has changed: 131 o netconf-config-change 133 o netconf-capability-change 135 o netconf-session-start 137 o netconf-session-end 139 o netconf-confirmed-commit 141 These event notifications used within the 'NETCONF' stream are 142 accessible to clients via the subscription mechanism described in 143 [RFC5277]. 145 This document introduces NMDA specific extension which allows a 146 client to receive 1 notifications for additional common system events 147 as follows: 149 apply-configuration-updated: Generated when a server with network 150 management protocol support interacts with hardware and detects 151 that a set of configurations are not applied or none of them are 152 not applied. Indicates the event and the current state of the 153 applied configuration or data inconsistency issue between intended 154 data initiated from the client and operational data saved in the 155 server. NMDA datastore compare [I-D.ietf-netmod-nmda-diff] can be 156 used to trigger consistency data check, i.e.,indicate the source 157 of configuration node and check which part of configuration data 158 is applied or which part of configuration data is not applied. A 159 server MAY report events for non-NETCONF management sessions (such 160 as RESTCONF,gPRC), using the 'session-id' value of zero. 162 The following figure shows event notification sequence defined in 163 this document. 165 +----------------------------+ 166 |Server (device) | 167 | | 168 | | 169 | +----------+ | 170 | | Intended | | 171 +------------+ | | datastore| | 172 | | | +----------+ | 173 |+----------+| | ^ | 174 || Intended || | | | 175 || config || | v | 176 |+----------+| | +-------------+ | 177 | |<----------------------> | | | 178 | Client | rpc | NETCONF | | 179 | (app) | | | engine | | 180 | |<---------------------- | | | 181 | | notification / \ | 183 +------------+ | / \ | 184 | / \ | 185 |+------------++---------+ | 186 || Operational||system |+ | 187 || datastore ||software ||+ | 188 || ||component||| | 189 |+------------++---------+|| | 190 | +---------+| | 191 | +---------+ | 192 +----------------------------+ 194 These notification messages are accessible to clients via either the 195 subscription mechanism described in [RFC5277] or dynamic subscription 196 mechanism and configured subscription mechanism described in [I- 197 D.ietf-netconf-netconf-event-notifications]. 199 2.2. Data Model Design 201 The data model is defined in the ietf-nmda-notifications YANG module. 202 Its structure is shown in the following figure. The notation syntax 203 follows [RFC8340]. 205 notifications: 206 +---n intent-configuration-update 207 +--ro app-tag? string 208 +--ro src-ds? identityref 209 +--ro dst-ds? identifyref 210 +--ro (filter-spec)? 211 | +--:(subtree-filter) 212 | | +--ro subtree-filter? 213 | +--:(xpath-filter) 214 | +--ro xpath-filter? yang:xpath1.0 {nc:xpath}? 215 |--ro apply-result enumeration 216 +--ro fail-applied-object* [edit-id] 217 +--ro edit-id string 218 +--ro operation enumeration 219 +--ro object? ypatch:target-resource-offset 220 +--ro value? 221 +--ro errors 222 +--ro error* [] 223 +--ro error-type enumeration 224 +--ro error-tag string 225 +--ro error-app-tag? string 226 +--ro error-path? instance-identifier 227 +--ro error-message? string 228 +--ro error-info? 230 The following are examples of a apply-configuration-updated 231 notification message: 233 234 2017-06-16T16:30:59.137045+09:00 235 236 ds--module-a 237 intended 238 operational 239 240 1 241 merge 242 /ietf-interfaces:interfaces-state 243 244 245 246 eth0 247 down 248 249 250 251 252 253 2 254 /ietf-system:system 255 256 protocol 257 mis-resource 258 \ 259 \/if:interfaces-state\ 260 \ 261 refer to resources that are not \ 262 \available or otherwise not physically present.\ 263 \ 264 265 266 267 269 2.3. Relation with NMDA Datastore Compare 271 NMDA datastore compare [I-D.ietf-netmod-nmda-diff] could be used to 272 check which part of configuration data is applied or which part of 273 configuration data is not applied,e.g.,If a client creates an 274 interface "et-0/0/0" but the interface does not physically exist at 275 this point, the interface will appear in but does not does 276 not exist in the . By comparing configuration 277 difference between and , the interface that 278 is not applied can be sorted out. Unlike [I-D.ietf-netmod-nmda- 279 diff], the notification message only focuses on the configuration 280 data that is not applied and the reason why the configuration changes 281 were not applied. Also system internal interactions with hardware is 282 needed within the server to make sure fail applied object is caused 283 by mis-resource or remnant Configuration, etc. 285 2.4. Definitions 287 This section presents the YANG module defined in this document. This 288 module imports data types from the 'ietf-datastores' module defined 289 in [RFC8342] and 'ietf-inet-types' module defined in [RFC6021]. 291 file "ietf-nmda-notifications@2019-06-19.yang" 292 module ietf-nmda-notifications { 293 yang-version 1.1; 294 namespace "urn:ietf:params:xml:ns:yang:ietf-nmda-notifications"; 295 prefix ndn; 296 import ietf-datastores { 297 prefix ds; 298 } 299 import ietf-inet-types { prefix inet; } 300 import ietf-yang-types { prefix yang;} 301 import ietf-yang-patch { 302 prefix ypatch; 303 } 304 import ietf-netconf { 305 prefix nc; 306 } 307 import ietf-restconf { prefix rc;} 308 organization 309 "IETF NETMOD (Network Modeling) Working Group"; 310 contact 311 "WG Web: 312 WG List: 314 Editor: Qin Wu 315 316 Editor: Rohit R Ranade 317 "; 318 description 319 "This module defines a YANG data model for use with the 320 NETCONF and RESTCONF protocol that allows the client to 321 receive additional common event notifications related to NMDA. 323 Copyright (c) 2012 IETF Trust and the persons identified as 324 the document authors. All rights reserved. 325 Redistribution and use in source and binary forms, with or 326 without modification, is permitted pursuant to, and subject 327 to the license terms contained in, the Simplified BSD License 328 set forth in Section 4.c of the IETF Trust's Legal Provisions 329 Relating to IETF Documents 330 (http://trustee.ietf.org/license-info). 331 This version of this YANG module is part of RFC xxxx; see 332 the RFC itself for full legal notices."; 334 revision 2019-06-19 { 335 description 336 "Initial version."; 337 reference "RFC xxx: NETCONF Base Notifications for NMDA"; 338 } 339 typedef session-id-or-zero-type { 340 type uint32; 341 description 342 "NETCONF Session Id or Zero to indicate none"; 343 } 344 feature error-info { 345 description 346 "This feature must 347 also be enabled for that session if error-info 348 can be advertised by the server. Otherwise, 349 this feature must not be enabled."; 350 } 351 grouping common-session-parms { 352 description 353 "Common session parameters to identify a 354 management session or internal interaction 355 on a set of configuration data."; 357 leaf username { 358 type string; 359 description 360 "Name of the user for the session."; 361 } 362 leaf source-host { 363 type inet:ip-address; 364 description 365 "Address of the remote host for the session."; 366 } 368 leaf session-id { 369 type session-id-or-zero-type; 370 description 371 "Identifier of the session. 372 A NETCONF session MUST be identified by a non-zero value. 373 A non-NETCONF session MAY be identified by the value zero."; 374 } 375 leaf app-tag { 376 type string; 377 description 378 "The application tag used to identify the managment session 379 or internal interaction on a set of configuration data."; 380 } 382 } 384 notification intent-configuration-updated { 385 description 386 "Generated when a server detects that a 387 intended configuration applied event has occurred. Indicates 388 the event and the current state of the intended data applying 389 procedure in progress."; 390 reference "RFC 8342, Section 5"; 391 uses common-session-parms; 392 leaf src-ds { 393 type identityref { 394 base ds:datastore; 395 } 396 description 397 "Indicates which datastore is 398 source of edit-data operation."; 399 } 400 leaf dst-ds { 401 type identityref { 402 base ds:datastore; 403 } 404 description 405 "Indicates which datastore is 406 target of edit-data operation."; 407 } 408 choice filter-spec { 409 description 410 "The content filter specification for this request."; 411 anydata subtree-filter { 412 description 413 "This parameter identifies the portions of the 414 target datastore to retrieve."; 415 reference 416 "RFC 6241: Network Configuration Protocol, Section 6."; 417 } 418 leaf xpath-filter { 419 if-feature nc:xpath; 420 type yang:xpath1.0; 421 description 422 "This parameter contains an XPath expression identifying 423 the portions of the target datastore to retrieve. 425 If the expression returns a node-set, all nodes in the 426 node-set are selected by the filter. Otherwise, if the 427 expression does not return a node-set, then the get-data 428 operation fails. 430 The expression is evaluated in the following XPath 431 context: 433 o The set of namespace declarations are those in 434 scope on the 'xpath-filter' leaf element. 436 o The set of variable bindings is empty. 438 o The function library is the core function library, 439 and the XPath functions defined in section 10 in 440 RFC 7950. 442 o The context node is the root node of the target 443 datastore."; 444 } 445 } 446 leaf apply-result { 447 type enumeration { 448 enum "partial-fail" { 449 description 450 "A set of configuration data is not applied."; 451 } 452 enum "fail" { 453 description 454 " None of configuration data is applied."; 455 } 456 enum "sucess" { 457 description 458 " All configuration data is applied."; 459 } 460 } 461 description 462 "Configuration data apply result."; 463 } 464 list fail-applied-object { 465 when "../apply-result = 'partial-fail'"; 466 key edit-id; 467 ordered-by user; 468 leaf edit-id { 469 type string; 470 description 471 "Response status is for the 'edit' list entry 472 with this 'edit-id' value."; 474 } 475 leaf operation { 476 type enumeration { 477 enum create { 478 description 479 "The target data node is created using the supplied 480 value, only if it does not already exist. The 481 'target' leaf identifies the data node to be 482 created, not the parent data node."; 483 } 484 enum delete { 485 description 486 "Delete the target node, only if the data resource 487 currently exists; otherwise, return an error."; 488 } 490 enum insert { 491 description 492 "Insert the supplied value into a user-ordered 493 list or leaf-list entry. The target node must 494 represent a new data resource. If the 'where' 495 parameter is set to 'before' or 'after', then 496 the 'point' parameter identifies the insertion 497 point for the target node."; 498 } 499 enum merge { 500 description 501 "The supplied value is merged with the target data 502 node."; 503 } 504 enum move { 505 description 506 "Move the target node. Reorder a user-ordered 507 list or leaf-list. The target node must represent 508 an existing data resource. If the 'where' parameter 509 is set to 'before' or 'after', then the 'point' 510 parameter identifies the insertion point to move 511 the target node."; 512 } 513 enum replace { 514 description 515 "The supplied value is used to replace the target 516 data node."; 517 } 518 enum remove { 519 description 520 "Delete the target node if it currently exists."; 521 } 523 } 524 mandatory true; 525 description 526 "The datastore operation requested for the associated 527 'edit' entry."; 528 } 529 leaf target { 530 type ypatch:target-resource-offset; 531 description 532 "Topmost node associated with the configuration change. 533 A server SHOULD set this object to the node within 534 the datastore that is being altered. A server MAY 535 set this object to one of the ancestors of the actual 536 node that was changed, or omit this object, if the 537 exact node is not known."; 538 } 539 anydata value { 540 description 541 "Value used for this edit operation. The anydata 'value' 542 contains the target resource associated with the 543 'target' leaf. 545 For example, suppose the target node is a YANG container 546 named foo: 548 container foo { 549 leaf a { type string; } 550 leaf b { type int32; } 551 } 553 The 'value' node contains one instance of foo: 555 556 557 some value 558 42 559 560 561 "; 562 } 563 uses rc:errors {if-feature error-info;} 564 description 565 "List for fail applied objects that is not applied. "; 566 } 567 } 568 } 569 571 3. Security Considerations 573 The YANG module defined in this memo is designed to be accessed via 574 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 575 secure transport layer and the mandatory-to-implement secure 576 transport is SSH, defined in [RFC6242]. 578 Some of the readable data nodes in this YANG module may be considered 579 sensitive or vulnerable in some network environments. It is thus 580 important to control read access (e.g., via get, get-config, or 581 notification) to these data nodes. These are the subtrees and data 582 nodes and their sensitivity/vulnerability: 584 /intent-configuration-update: 586 Event type itself indicates that intent based configuration has 587 been updated. This event could alert an attacker that a datastore 588 may have been altered. 590 /intent-configuration-updated/apply-result: 592 Indicates the specific intent based configuration update event 593 state change that occurred. A value of 'success' probably 594 indicates that intent based configuration has been applied 595 successfully. 597 4. IANA Considerations 599 This document registers one XML namespace URN in the 'IETF XML 600 registry', following the format defined in [RFC3688]: 602 URI: urn:ietf:params:xml:ns:yang:ietf-nmda-notifications 604 Registrant Contact: The IESG. 606 XML: N/A, the requested URI is an XML namespace. 608 This document registers one module name in the 'YANG Module Names' 609 registry, defined in [RFC7950]: 611 name: ietf-nmda-notifications 613 prefix: ndn 615 namespace: urn:ietf:params:xml:ns:yang:ietf-nmda-notifications 617 RFC: xxxx 619 5. Acknowledgements 621 Thanks to Juergen Schoenwaelder, Alex Clemm,Carey Timothy and Andy 622 Berman, Sterne Jason to review this draft and Thank Xiaojian Ding 623 provide important input to the initial version of this document. 625 6. Contributors 627 Chong Feng 628 Huawei 629 Email:frank.fengchong@huawei.com 631 7. Normative References 633 [I-D.ietf-netmod-nmda-diff] 634 Clemm, A., Qu, Y., Tantsura, J., and A. Bierman, 635 "Comparison of NMDA datastores", draft-ietf-netmod-nmda- 636 diff-01 (work in progress), May 2019. 638 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 639 Requirement Levels", BCP 14, RFC 2119, 640 DOI 10.17487/RFC2119, March 1997, 641 . 643 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 644 DOI 10.17487/RFC3688, January 2004, 645 . 647 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 648 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, 649 . 651 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 652 the Network Configuration Protocol (NETCONF)", RFC 6020, 653 DOI 10.17487/RFC6020, October 2010, 654 . 656 [RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types", 657 RFC 6021, DOI 10.17487/RFC6021, October 2010, 658 . 660 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 661 and A. Bierman, Ed., "Network Configuration Protocol 662 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 663 . 665 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 666 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 667 . 669 [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) 670 Base Notifications", RFC 6470, DOI 10.17487/RFC6470, 671 February 2012, . 673 [RFC8072] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Patch 674 Media Type", RFC 8072, DOI 10.17487/RFC8072, February 675 2017, . 677 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 678 and R. Wilton, "Network Management Datastore Architecture 679 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 680 . 682 Appendix A. Changes between revisions 684 v01 - v03 686 o Change notification name into intent-configuration update. 688 o Change title into NMDA Base event for intent based configuration 689 update. 691 o Clarify the usage of NMDA base event and relation with NMDA diff 692 work. 694 v01 - v00 696 o Add application tag support and use additional parameters to 697 identify management session. 699 o Remove apply-intended-start and apply-intended-end two 700 notifications since they are not needed based on discussion. 702 Authors' Addresses 704 Qin Wu 705 Huawei 706 101 Software Avenue, Yuhua District 707 Nanjing, Jiangsu 210012 708 China 710 Email: bill.wu@huawei.com 711 Ran Tao 712 Huawei 714 Email: taoran20@huawei.com 716 Rohit R Ranade 717 Huawei 718 Divyashree Techno Park, Whitefield 719 Bangalore, Karnataka 560066 720 India 722 Email: rohitrranade@huawei.com