idnits 2.17.00 (12 Aug 2021) /tmp/idnits62574/draft-wang-netmod-module-revision-management-01.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 are 20 instances of too long lines in the document, the longest one being 31 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 168 has weird spacing: '...eration ide...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (September 18, 2018) is 1334 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: 'RFC6241' is mentioned on line 128, but not defined == Unused Reference: 'RFC7952' is defined on line 963, but no explicit reference was found in the text == Outdated reference: draft-ietf-netconf-rfc7895bis has been published as RFC 8525 == Outdated reference: draft-ietf-netmod-rfc6087bis has been published as RFC 8407 == Outdated reference: A later version (-02) exists of draft-verdt-netmod-yang-versioning-reqs-00 ** Downref: Normative reference to an Informational draft: draft-verdt-netmod-yang-versioning-reqs (ref. 'I-D.verdt-netmod-yang-versioning-reqs') ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD Working Group M. Wang 3 Internet-Draft Q. Wu 4 Intended status: Standards Track Huawei 5 Expires: March 22, 2019 A. Wang 6 China Telecom 7 September 18, 2018 9 A YANG Data Model for module revision management 10 draft-wang-netmod-module-revision-management-01 12 Abstract 14 This document defines a YANG Data Model for module revision change 15 management. It is intended this model be used by vendors who support 16 multiple revisions of the same YANG module in their systems but 17 implement only one revision of a module. In addition, this document 18 introduces a new generic mechanism based on RPC, denoted as module- 19 revision-change, that allow datanode backwards compatibility 20 detection and provide a report on change type and change details of a 21 YANG module with two or multiple revisions that is defined in design 22 time., e.g.,identifies a place in the node hierarchy where data node 23 gets changed or new data gets inserted and indicate whether the 24 change to the data node is backward compatible. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on March 22, 2019. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Design of YANG data model for module revision management . . 4 63 3.1. yang-modules . . . . . . . . . . . . . . . . . . . . . . 6 64 3.1.1. yang-modules/module . . . . . . . . . . . . . . . . . 6 65 3.1.2. yang-modules/change-log . . . . . . . . . . . . . . . 6 66 3.2. RPC definition for module revision change . . . . . . . . 6 67 3.2.1. Usage Example . . . . . . . . . . . . . . . . . . . . 6 68 4. YANG Extension for Purpose Marking . . . . . . . . . . . . . 8 69 4.1. Usage Example: Add New Function . . . . . . . . . . . . . 8 70 4.2. Usage example: Bug Fix . . . . . . . . . . . . . . . . . 10 71 5. Library Augmentation . . . . . . . . . . . . . . . . . . . . 12 72 6. Multiple revisions module management . . . . . . . . . . . . 13 73 7. Yang Data Model Definition . . . . . . . . . . . . . . . . . 13 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 76 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 77 11. Normative References . . . . . . . . . . . . . . . . . . . . 22 78 Appendix A. Example of Module Revision Management . . . . . . . 23 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 81 1. Introduction 83 The revised Network Management Datastore Architecture (NMDA) defines 84 a set of new datastores that each hold YANG-defined data [RFC7950] 85 and represent a different "viewpoint" on the data that is maintained 86 by a server. To support the NMDA, many modules may need to be 87 updated or restructured especially for some published non-NMDA 88 modules, the model should be republished with an NMDA-compatible 89 structure, deprecating non-NMDA constructs 90 [I-D.ietf-netmod-rfc6087bis]. Therefore, how to support hackward- 91 compatible and indicate the module's changes is an issue. 93 As described in [RFC7950] , a module name MUST NOT be changed when 94 definitions contained in a module are available to be imported by any 95 other module and are referenced in "import" statements via the module 96 name. In some case, when we make non-backward compatible updates, 97 the module name might be forced to change, according to[RFC7950] 98 module update rule. 100 In order to provide an easy way to indicate how backward-compatible a 101 given YANG module actually is, this document defines a YANG Data 102 Model for module revision change management. It is intended this 103 model be used by vendors who support multiple revisions of the same 104 YANG module in their systems but implement only one revision of a 105 module. In addition, this document introduces a new generic 106 mechanism based on RPC, denoted as module-revision-change, that allow 107 Datanode backwards compatibility detection and provide a report on 108 change type and change details of a YANG module with two or multiple 109 revisions that is defined in design time., e.g.,identifies a place in 110 the node hierarchy where data node gets changed or new data gets 111 inserted and indicate whether the change to the data node is backward 112 compatible. 114 In addition, in order to identify whether changes between two 115 revisions represent bug fixes, new functionality, or both, etc 116 [I-D.verdt-netmod-yang-versioning-reqs], this document also defines a 117 new YANG extension statement which can help the user to understand 118 the purpose of changing a specific node. See More details in section 119 4. 121 2. Terminologies 123 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in BCP 126 14, [RFC2119]. 128 The following terms are defined in [RFC6241] and are not redefined 129 here: 131 o client 133 o notification 135 o server 137 The following terms are defined in [RFC7950] and are not redefined 138 here: 140 action 142 container 143 list 145 operation 147 3. Design of YANG data model for module revision management 149 The "ietf-module-revision-management" module provides per revision 150 the module change type and change details used by a server. This 151 module is defined using YANG version 1.1, but it supports the 152 description of YANG modules written in any revision of YANG. 154 All data nodes in "ietf-module-revision-management" are "config 155 false", and thus accessible in the operational state datastore. 157 Following is the YANG Tree Diagram for the "ietf-module-revision- 158 management" module: 160 module: ietf-module-revision 161 +--ro yang-modules 162 +--ro module* [name revision] 163 +--ro name yang:yang-identifier 164 +--ro revision yanglib:revision-identifier 165 +--ro backward-compatible? boolean 166 +--ro revision-change-log* [index] 167 +--ro index uint32 168 +--ro change-operation identityref 169 +--ro (yang-statements)? 170 +--:(data-definition-statement) 171 | +--ro data-definition 172 | +--ro target-node yang:xpath1.0 173 | +--ro location-point? yang:xpath1.0 174 | +--ro where? enumeration 175 | +--ro data-definition? 176 +--:(other-statement) 177 +--ro other-statement 178 +--ro statement-name? identityref 179 +--ro statement-definition? 180 +--ro substatements* [statement-name] 181 +--ro statement-name identityref 182 +--ro substatement-definition? 183 augment /yanglib:yang-library/yanglib:module-set/yanglib:module: 184 +--ro backward-compatible? boolean 185 augment /yanglib:yang-library/yanglib:module-set/yanglib:module/yanglib:submodule: 186 +--ro backward-compatible? boolean 188 rpcs: 189 +---x module-revision-change 190 +---w input 191 | +---w source module-name yang:yang-identifier 192 | +---w source-revision? yanglib:revision-identifier 193 | +---w target module-name yang:yang-identifier 194 | +---w target-revision? yanglib:revision-identifier 195 +--ro output 196 +--ro (status-response)? 197 | +--:(wrong-match) 198 | | +--ro wrong-match? empty 199 | +--ro data-nodes* [data-node-name] 200 | +--ro data-node-name string 201 | +--ro is-new-node? boolean 202 | +--ro change-operation? identityref 204 3.1. yang-modules 206 This container holds all per revision the module discrepancy 207 information used by a server. 209 3.1.1. yang-modules/module 211 This mandatory list contains one entry for each revision of each YANG 212 module that is used by the server. It is possible for multiple 213 revisions of the same module to be imported, in addition to an entry 214 for the revision that is implemented by the server. Multiple 215 revisions of the same module are either backward-compatible or non 216 backward-compatible. 218 3.1.2. yang-modules/change-log 220 This list contains one entry for each schema node change from 221 previous revision known by the server, and identifies schema node 222 change path,location, operation and associated with corresponding 223 schema node in the "change-log" list. Each revision of the YANG 224 module has multiple entries. 226 A change log is an ordered collection of changes that are applied to 227 one revision of YANG module. Each change is identified by an 228 "index", and it has an change operation ("create", "delete","move", 229 "modify") that is applied to the target resource. Each change can be 230 applied to a sub-resource "target" within the target resource. If 231 the operation is "move", then the "where" parameter indicates how the 232 node is moved. For values "before" and "after", the "point" 233 parameter specifies the data node insertion point. 235 Each entry within a change log MUST identify exactly one data 236 definition change or other statement change. 238 3.2. RPC definition for module revision change 240 The "module-revision-change" rpc statement is defined to retrieve the 241 schema data node changes between any two revisions of the same 242 module, i.e. the data node that get updated or newly added during 243 module revision change. This rpc statement takes module 244 identification information as input, and provides the list of data 245 nodes that make changes or are newly added in the later revision. 247 3.2.1. Usage Example 249 For example, there are two revisions of the same module, the yang 250 codes are shown as below: 252 module example-a{ 253 yang-version 1.1; 254 namespace "urn:example:a"; 255 prefix "a"; 257 organization "foo."; 258 contact "fo@example.com"; 259 description 260 "foo."; 262 revision 2017-12-01 { 263 description "Initial revision."; 264 } 266 container system { 267 leaf host-name { 268 type string; 269 description 270 "Hostname for this system."; 271 } 272 } 273 } 275 module example-a{ 276 yang-version 1.1; 277 namespace "urn:example:a"; 278 prefix "a"; 280 organization "foo."; 281 contact "fo@example.com"; 282 description 283 "foo."; 285 revision 2017-12-20{ 286 description "Initial revision."; 287 } 289 container system { 290 leaf host-name { 291 type string; 292 description 293 "Hostname for this system."; 294 } 295 leaf b { 296 type string; 297 description 298 "foo"; 299 } 301 } 303 If we initiate a "module-revision-change" RPC to retrieve the changes 304 between two revisions of module "a", the NETCONF XML example are 305 shown as below: 307 309 310 example-a 311 1.0.0 312 2.0.0 313 314 316 318 319 0001 320 b 321 true 322 major-change 323 324 326 4. YANG Extension for Purpose Marking 328 In order to identify whether changes between two revisions represent 329 bug fixes, new functionality, or both, etc 330 [I-D.verdt-netmod-yang-versioning-reqs], purpose marking are defined 331 via the YANG extension "mr:purpose". This YANG extension statement 332 is defined in the module "ietf-module-revision" (Section 7). This 333 YANG extension can help the user to understand the purpose of 334 changing a specific node. 336 4.1. Usage Example: Add New Function 338 For example, there is a YANG data model "example-a", the yang codes 339 are shown as below: 341 module example-a{ 342 yang-version 1.1; 343 namespace "urn:example:a"; 344 prefix "a"; 346 organization "foo."; 347 contact "fo@example.com"; 348 description 349 "foo."; 351 revision 2017-12-01 { 352 description "Initial revision."; 353 } 355 container system { 356 leaf host-name { 357 type string; 358 description 359 "Hostname for this system."; 360 } 361 } 362 } 364 When the author of "example-a" designs a new revision to add some new 365 attributes, the "mr:purpose" marking can be used to mark the purpose 366 of the updates. For example: 368 module example-a{ 369 yang-version 1.1; 370 namespace "urn:example:a"; 371 prefix "a"; 373 organization "foo."; 374 contact "fo@example.com"; 375 description 376 "foo."; 378 revision 2017-12-20{ 379 description "Initial revision."; 380 } 382 container system { 383 leaf host-name { 384 type string; 385 description 386 "Hostname for this system."; 387 } 388 leaf b { 389 type string; 390 mr:purpose "new-function"; 391 description 392 "foo"; 394 } 395 } 397 4.2. Usage example: Bug Fix 399 For example, there are some bugs in a published model "example-b", 400 the yang codes are shown as below: 402 module example-b{ 403 yang-version 1.1; 404 namespace "urn:example:b"; 405 prefix "b"; 407 organization "foo."; 408 contact "fo@example.com"; 409 description 410 "foo."; 412 revision 2017-12-01 { 413 description "Initial revision."; 414 } 416 container system { 417 leaf host-name { 418 type uint32; 419 description 420 "Hostname for this system."; 421 } 422 } 423 } 425 The following updates allow to fix bugs in a backward-compatible way: 427 module example-b{ 428 yang-version 1.1; 429 namespace "urn:example:b"; 430 prefix "b"; 432 organization "foo."; 433 contact "fo@example.com"; 434 description 435 "foo."; 437 revision 2017-12-01 { 438 description "Initial revision."; 439 } 441 container system { 442 leaf host-name-update { 443 type string; 444 mr:purpose "bug-fix"; 445 description 446 "Hostname for this system."; 447 } 448 leaf host-name { 449 type uint32; 450 status deprecated; 451 description 452 "Hostname for this system."; 453 } 454 } 455 } 457 5. Library Augmentation 459 Backward compatibility for each revision of YANG module can also be 460 read using the yang library [I-D.ietf-netconf-rfc7895bis] if a server 461 supports both YANG library and the augmentation defined below. If a 462 server supports indication of backward compatibility forone revision 463 of and the YANG module, it SHOULD also support the "ietf-module- 464 revision" module. 466 The tree associated with the defined augmentation is: 468 module: ietf-module-revisions 469 augment /yanglib:yang-library/yanglib:modules/yanglib:module: 470 +--ro backward-compatible? bool 472 augment /yanglib:yanglibrary/yanglib:modules/yanglib:module 473 /yanglib:submodule: 474 +--ro backward-compatible? bool 476 6. Multiple revisions module management 478 As experience is gained with a module, it may be desirable to support 479 multiple revisions of that module in their systems but implement one 480 revision of a module at each time. To indicate the details changes 481 of that module, e.g., identifies schema node change path,location, 482 operation and associated with corresponding schema node, it will be 483 desirable to use 'ietf-module-revision' defined in this document to 484 manage all the revisions of that module and keep track of module 485 change discrepancy in different revision, especially when the new 486 revision is not backward compatible with previous revision. 488 7. Yang Data Model Definition 490 file "ietf-module-revision@2018-08-08.yang" 492 module ietf-module-revision { 493 yang-version 1.1; 494 namespace "urn:ietf:params:xml:ns:yang:ietf-module-revision"; 495 prefix ml; 497 import ietf-yang-library { 498 prefix yanglib; 499 } 500 import ietf-yang-types { 501 prefix yang; 502 } 504 organization 505 "IETF Network Modeling (NETMOD) Working Group"; 506 contact 507 "WG Web: 509 WG List: 511 Author: Qin Wu 512 513 Zitao Wang 514 "; 515 description 516 "This YANG module defines an module log."; 518 revision 2018-08-08 { 519 description 520 "Initial revision."; 521 reference "RFC XXXX: Using Metadata with YANG for Module revisions"; 522 } 524 identity operation-type { 525 description 526 "Abstract base identity for the operation type "; 527 } 529 identity create { 530 base operation-type; 531 description 532 "Denotes create new data nodes"; 533 } 535 identity delete { 536 base operation-type; 537 description 538 "Denotes delete the target node"; 539 } 541 identity move { 542 base operation-type; 543 description 544 "Denote move the target node."; 545 } 547 identity modify { 548 base operation-type; 549 description 550 "Denote modify the target data node."; 551 } 553 identity statement-type { 554 description 555 "Base identity for statement type"; 556 } 558 identity feature-statement { 559 base statement-type; 560 description 561 "feature statement, if this type be chose, it means that the 562 feature or if-feature statement been modified"; 563 } 564 identity identity-statement { 565 base statement-type; 566 description 567 "identity statement, if this type be chose, it means that the 568 identity statement been modified, for example, add new identity, etc."; 569 } 571 identity grouping-statement { 572 base statement-type; 573 description 574 "grouping statement, if this type be chose, it means that the grouping 575 statement been modified."; 576 } 578 identity typedef-statement { 579 base statement-type; 580 description 581 "typedef statement, if this type be chose, it means that the typedef 582 statement been modified."; 583 } 585 identity augment-statement { 586 base statement-type; 587 description 588 "augment statement, if this type be chose, it means that the augment 589 statement been modified."; 590 } 592 identity rpc-statement { 593 base statement-type; 594 description 595 "rpc statement, if this type be chose, it means that the rpc 596 statement been modified."; 597 } 599 identity notification-statement { 600 base statement-type; 601 description 602 "notification statement, if this type be chose, it means that the notification 603 statement been modified."; 604 } 606 extension purpose { 607 argument name; 608 description 609 "The purpose can be used to mark the data nodes change purpose. 610 The name argument can be specified in the following recommended mode 611 - bug-fix, which can help user to understand the data nodes' changes present bug fix, 612 - new-function, which can help user to understand the data nodes' changes present new function, 613 - nmda-conform, which can help user to understand the data nodes' changes conform to NMDA, 615 and note that the user can argument the purpose name according to their sepcific requirements."; 616 } 618 grouping data-definition { 619 container data-definition { 620 leaf target-node { 621 type yang:xpath1.0; 622 mandatory true; 623 description 624 "Identifies the target data node for update. 625 Notice that, if the update-type equal to move or delete, 626 this target-node must point to the data node of old version. 627 \t 628 For example, suppose the target node is a YANG leaf named a, 629 and the previous version is: 630 \t 631 container foo { 632 leaf a { type string; } 633 leaf b { type int32; } 634 } 635 \t 636 the new version is: 637 container foo { 638 leaf b {type int32;} 639 } 640 \t 641 Therefore, the targe-node should be /foo/a."; 642 } 643 leaf location-point { 644 type yang:xpath1.0; 645 description 646 "Identifies the location point where the updates happened."; 647 } 648 leaf where { 649 when "derived-from-or-self(../../change-operation, 'move')" { 650 description 651 "This leaf only applies for 'move' 652 updates."; 653 } 654 type enumeration { 655 enum "before" { 656 description 657 "Insert or move a data node before the data resource 658 identified by the 'point' parameter."; 660 } 661 enum "after" { 662 description 663 "Insert or move a data node after the data resource 664 identified by the 'point' parameter."; 665 } 666 enum "first" { 667 description 668 "Insert or move a data node so it becomes ordered 669 as the first entry."; 670 } 671 enum "last" { 672 description 673 "Insert or move a data node so it becomes ordered 674 as the last entry."; 675 } 676 } 677 default "last"; 678 description 679 "Identifies where a data resource will be inserted 680 or moved."; 681 } 682 anydata data-definition { 683 when "derived-from-or-self(../../change-operation, 'modify')" { 684 description 685 "This nodes only be present when 686 the 'change-operation' equal to 'modify'."; 687 } 688 description 689 "This nodes used for present the definitions before updated. 690 And this nodes only be present when 691 the 'change-operation' equal to 'modify'."; 692 } 693 description 694 "Container for data statement"; 695 } 696 description 697 "Grouping for data definition"; 698 } 700 grouping other-statement { 701 container other-statement { 702 leaf statement-name { 703 type identityref { 704 base statement-type; 705 } 706 description 707 "Statement name, for example, identity, feature, typedef, etc."; 709 } 710 anydata statement-definition { 711 description 712 "This nodes used for present new the definitions."; 713 } 714 list substatements { 715 key "statement-name"; 716 leaf statement-name { 717 type identityref { 718 base statement-type; 719 } 720 description 721 "Statement name, for example, identity, feature, typedef, etc."; 722 } 723 anydata substatement-definition { 724 description 725 "This nodes used for present new the definitions."; 726 } 727 description 728 "List for substatements updates"; 729 } 730 description 731 "Container for header statement updates"; 732 } 733 description 734 "Grouping for header statement"; 735 } 737 grouping change-log { 738 list revision-change-log { 739 key "index"; 740 leaf index { 741 type uint32; 742 description 743 "Index for module change log"; 744 } 745 leaf change-operation { 746 type identityref { 747 base operation-type; 748 } 749 mandatory true; 750 description 751 "This leaf indicate the change operation, such as create, move, delete, modify, etc."; 752 } 753 choice yang-statements { 754 description 755 "Choice for various YANG statements that have been impacted."; 756 case data-definition-statement { 757 uses data-definition; 758 } 759 case other-statement { 760 uses other-statement; 761 } 762 } 763 description 764 "List for module revision change log"; 765 } 766 description 767 "Grouping for module revision change log"; 768 } 770 container yang-modules { 771 config false; 772 list module { 773 key "name revision"; 774 leaf name { 775 type yang:yang-identifier; 776 description 777 "The YANG module or submodule name."; 778 } 779 leaf revision { 780 type yanglib:revision-identifier; 781 description 782 "The YANG module or submodule revision date. If no revision 783 statement is present in the YANG module or submodule, this 784 leaf is not instantiated."; 785 } 786 leaf backward-compatible { 787 type boolean; 788 description 789 "Indicates whether it is a backward compatible version. 790 If this parameter is set to true, it means that this version is 791 a backwards compatible version"; 792 } 793 uses change-log; 794 description 795 "List for module updated log"; 796 } 797 description 798 "This container present the modules updated log."; 799 } 800 augment "/yanglib:yang-library/yanglib:module-set/yanglib:module" { 801 description 802 "Augment the yang library with backward compatibility indication."; 803 leaf backward-compatible { 804 type boolean; 805 description 806 "backward compatibility indication."; 807 } 808 } 809 augment "/yanglib:yang-library/yanglib:module-set/yanglib:module/yanglib:submodule" { 810 description 811 "Augment the yang library with backward compatibility indication."; 812 leaf backward-compatible { 813 type boolean; 814 description 815 "backward compatibility indication."; 816 } 817 } 818 rpc module-revision-change { 819 description 820 "Module Node change query operation."; 821 input { 822 leaf source-module-name { 823 type yang:yang-identifier; 824 mandatory true; 825 description 826 "The Source YANG module or submodule name."; 827 } 828 leaf source-revision { 829 type yanglib:revision-identifier; 830 description 831 "The Source YANG module revision date. If no revision 832 statement is present in the YANG module or submodule, this 833 leaf is not instantiated."; 834 } 835 leaf target-module-name { 836 type yang:yang-identifier; 837 mandatory true; 838 description 839 "The Target YANG module or submodule name."; 840 } 841 leaf target-revision { 842 type yanglib:revision-identifier; 843 description 844 "The target YANG module revision date. If no revision 845 statement is present in the YANG module or submodule, this 846 leaf is not instantiated."; 847 } 848 } 849 output { 850 choice status-response{ 851 leaf wrong-match{ 852 type empty; 853 description 854 "This leaf indicates that two modules have nothing in common."; 855 } 856 list data-nodes { 857 key "data-node-name"; 858 description 859 "Each entry represents a data node of a given module that 860 have been changed from source revision of 861 a module to target revision of the module."; 862 leaf data-node-name { 863 type string; 864 description 865 "a data node name of a given module that 866 has been changed."; 867 } 868 leaf is-new-node { 869 type boolean; 870 description 871 "indicate the data node is newly introduced node in the target revision."; 872 } 873 leaf change-operation { 874 type identityref { 875 base operation-type; 876 } 877 description 878 "This leaf indicate the change operation, 879 such as create, move, delete, modify, etc."; 880 } 881 } 882 } 883 } 884 } 885 } 887 889 8. Security Considerations 891 This document defines a mechanism that is put at a place in the node 892 hierarchy where data node gets changed or new data gets inserted and 893 indicate whether the change to the data node is backward compatible 894 and as such doesn't introduce new security issues. 896 9. IANA Considerations 898 This document registers a URI in the IETF XML registry [RFC3688]. 899 Following the format in [RFC3688], the following registration is 900 requested to be made: 902 --------------------------------------------------------------------- 903 URI: urn:ietf:params:xml:ns:yang:ietf-module-revision 905 Registrant Contact: The NETMOD WG of the IETF. 907 XML: N/A, the requested URI is an XML namespace. 908 --------------------------------------------------------------------- 910 This document registers a YANG module in the YANG Module Names 911 registry [RFC6020]. 913 --------------------------------------------------------------------- 914 Name: ietf-module-revision 915 Namespace: urn:ietf:params:xml:ns:yang:ietf-module-revision 916 Prefix: md 917 Reference: RFC xxxx 918 --------------------------------------------------------------------- 920 10. Acknowledgements 922 This work is motivated from the discussions of module version in IETF 923 100 Singapore meeting. Thanks to Juergen Schoenwaelder and Adrian 924 Farrel for useful comments on this work. 926 11. Normative References 928 [I-D.ietf-netconf-rfc7895bis] 929 Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 930 and R. Wilton, "YANG Library", draft-ietf-netconf- 931 rfc7895bis-04 (work in progress), January 2018. 933 [I-D.ietf-netmod-rfc6087bis] 934 Bierman, A., "Guidelines for Authors and Reviewers of YANG 935 Data Model Documents", draft-ietf-netmod-rfc6087bis-15 936 (work in progress), December 2017. 938 [I-D.verdt-netmod-yang-versioning-reqs] 939 Clarke, J., "YANG Module Versioning Requirements", draft- 940 verdt-netmod-yang-versioning-reqs-00 (work in progress), 941 July 2018. 943 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 944 Requirement Levels", March 1997. 946 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 947 DOI 10.17487/RFC3688, January 2004, 948 . 950 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 951 the Network Configuration Protocol (NETCONF)", RFC 6020, 952 DOI 10.17487/RFC6020, October 2010, 953 . 955 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 956 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 957 . 959 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 960 RFC 7950, DOI 10.17487/RFC7950, August 2016, 961 . 963 [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", 964 RFC 7952, DOI 10.17487/RFC7952, August 2016, 965 . 967 Appendix A. Example of Module Revision Management 969 This section provides an example to generate XML snippet of ietf- 970 module-revision based on the changes between the new revision of 971 interface model as specified in [draft-ietf-netmod-rfc7223bis] and 972 the old revision of interface model as specified in [RFC7223]. 974 975 976 ietf-interfaces 977 2018-01-09 978 false 979 980 0001 981 delete 982 983 984 985 /if:interfaces-state 986 987 988 989 991 992 0002 993 create 994 995 996 997 feature-statement 998 999 feature if-mib { 1000 description 1001 "This feature indicates that the device implements 1002 the IF-MIB."; 1003 reference 1004 "RFC 2863: The Interfaces Group MIB"; 1005 } 1006 1007 1008 1009 1010 1012 1013 0003 1014 modify 1015 1016 1017 1018 1019 /if:interfaces/if:interface/if:link-up-down-trap-enable 1020 1021 1022 leaf link-up-down-trap-enable { 1023 if-feature if-mib; // add if-feature statement 1024 type enumeration { 1025 .... 1026 1027 1028 1029 1030 1032 1033 0004 1034 move 1035 1036 1037 1038 1039 /if:interfaces-state/if:interface/if:admin-status 1040 1041 1042 /if:interfaces/if:interface/link-up-down-trap-enable 1043 1044 after 1045 1047 1048 1050 1051 0005 1052 move 1053 1054 1055 1056 1057 /if:interfaces-state/if:interface/if:statistics 1058 1059 1060 /if:interfaces/if:interface/if:speed 1061 1062 after 1063 1064 1065 1066 ....... 1067 1068 1070 Authors' Addresses 1072 Michael Wang 1073 Huawei Technologies,Co.,Ltd 1074 101 Software Avenue, Yuhua District 1075 Nanjing 210012 1076 China 1078 Email: wangzitao@huawei.com 1080 Qin Wu 1081 Huawei 1082 101 Software Avenue, Yuhua District 1083 Nanjing, Jiangsu 210012 1084 China 1086 Email: bill.wu@huawei.com 1087 Aijun Wang 1088 China Telecom 1089 Beiqijia Town, Changping District 1090 Beijing, Beijing 102209 1091 China 1093 Email: wangaj.bri@chinatelecom.cn