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