-
Notifications
You must be signed in to change notification settings - Fork 3
/
draft-rwilton-netmod-yang-packages.xml
2482 lines (2243 loc) · 95.3 KB
/
draft-rwilton-netmod-yang-packages.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "reference.RFC.2119.xml">
<!ENTITY RFC5246 SYSTEM "reference.RFC.5246.xml">
<!ENTITY RFC6020 SYSTEM "reference.RFC.6020.xml">
<!ENTITY RFC6241 SYSTEM "reference.RFC.6241.xml">
<!ENTITY RFC6242 SYSTEM "reference.RFC.6242.xml">
<!ENTITY RFC6536 SYSTEM "reference.RFC.6536.xml">
<!ENTITY RFC7895 SYSTEM "reference.RFC.7895.xml">
<!ENTITY RFC7950 SYSTEM "reference.RFC.7950.xml">
<!ENTITY RFC8199 SYSTEM "reference.RFC.8199.xml">
<!ENTITY RFC8040 SYSTEM "reference.RFC.8040.xml">
<!ENTITY RFC8174 SYSTEM "reference.RFC.8174.xml">
<!ENTITY RFC8342 SYSTEM "reference.RFC.8342.xml">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" ipr="trust200902" docName="draft-rwilton-netmod-yang-packages-03">
<front>
<title abbrev="YANG Packages">YANG Packages</title>
<author initials="R." surname="Wilton" fullname="Robert Wilton" role="editor">
<organization>Cisco Systems, Inc.</organization>
<address>
<email>rwilton@cisco.com</email>
</address>
</author>
<author initials="R." surname="Rahman" fullname="Reshad Rahman">
<organization>Cisco Systems, Inc.</organization>
<address>
<email>rrahman@cisco.com</email>
</address>
</author>
<author initials="J." surname="Clarke" fullname="Joe Clarke">
<organization>Cisco Systems, Inc.</organization>
<address>
<email>jclarke@cisco.com</email>
</address>
</author>
<author initials="J." surname="Sterne" fullname="Jason Sterne">
<organization abbrev="Nokia">
Nokia
</organization>
<address>
<email>jason.sterne@nokia.com</email>
</address>
</author>
<author fullname="Bo Wu" initials="B" surname="Wu">
<organization>Huawei</organization>
<address>
<email>lana.wubo@huawei.com</email>
</address>
</author>
<date/>
<abstract>
<t>
This document defines YANG packages, a versioned organizational
structure holding a set of related YANG modules, that collectively
define a YANG schema. It describes how packages: are represented on a
server, can be defined in offline YANG instance data documents, and can
be used to define the schema associated with YANG instance data
documents.
</t>
</abstract>
</front>
<middle>
<section anchor="terminology" title="Terminology and Conventions">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all
capitals, as shown here.</t>
<t>This document uses terminology introduced in the YANG
versioning requirements draft <xref
target="I-D.verdt-netmod-yang-versioning-reqs"/>.</t>
<t>This document also makes of the following terminology
introduced in the Network Management Datastore Architecture
<xref target="RFC8342"/>:
<list style="symbols">
<t>datastore schema</t>
</list>
</t>
<t>This document also makes of the following terminology
introduced in the YANG 1.1 Data Modeling Language
<xref target="RFC7950"/>:
<list style="symbols">
<t>data node</t>
</list>
</t>
<t>In addition, this document defines the following terminology:
<list style="symbols">
<t>YANG schema: A datastore schema, not bound to any particular
datastore.</t>
<t>YANG package: An organizational structure holding a collection of
YANG modules related by some common purpose, normally defined in a YANG
instance data file. A YANG package defines a YANG schema by specifying
a set of YANG modules revisions, package versions, mandatory features,
and deviations. YANG packages are defined in <xref
target="package"/>.</t>
<t>backwards-compatible (BC) change: When used in the context of a YANG
module, it follows the definition in Section 3.1.1 of <xref
target="I-D.verdt-netmod-yang-module-versioning"/>. When used in the
context of a YANG package, it follows the definition in <xref
target="bc_package_change"/>.</t>
<t>non-backwards-compatible (NBC) change: When used in the context of a
YANG module, it follows the definition in Section 3.1.2 of <xref
target="I-D.verdt-netmod-yang-module-versioning"/>. When used in the
context of a YANG package, it follows the definition in <xref
target="bc_package_change"/>.</t>
<t>editorial change: When used in the context of a YANG module, it
follows the definition of an 'editorial change' in 3.2 of <xref
target="I-D.verdt-netmod-yang-semver"/>. When used in the context of a
YANG package, it follows the definition in <xref
target="editorial_package_change"/>.</t>
</list>
</t>
</section>
<section anchor="intro" title="Introduction">
<t>This document defines and describes the YANG <xref target="RFC7950"/>
constructs that are used to define and use YANG packages.</t>
<t>A YANG package is an organizational structure that groups a set of YANG
modules together into a consistent versioned definition to serve a common
purpose. For example, a YANG package could define the set of YANG modules
required to implement an L2VPN service on a network device. YANG packages
can themselves refer to, and reuse, other package definitions.</t>
<t>Non-normative examples of YANG packages are provided in the
appendices.</t>
</section>
<section anchor="background" title="Background on YANG packages">
<t>It has long been acknowledged within the YANG community that
network management using YANG requires a unit of organization
and conformance that is broader in scope than individual YANG
modules.</t>
<t>'The YANG Package Statement' <xref
target="I-D.bierman-netmod-yang-package"/> proposed a YANG package
mechanism based on new YANG language statements, where a YANG package is
defined in a file similar to how YANG modules are defined, and would
require enhancements to YANG compilers to understand the new statements
used to define packages.</t>
<t>OpenConfig <xref target="openconfigsemver"/> describes an approach to
versioning 'bundle releases' based on git tags. I.e. a set of modules, at
particular versions, can be marked with the same release tag to indicate
that they are known to interoperate together.</t>
<t>The NETMOD WG in general, and the YANG versioning design team in
particular, are exploring solutions <xref
target="I-D.verdt-netmod-yang-solutions"/> to the YANG versioning
requirements, <xref target="I-D.verdt-netmod-yang-versioning-reqs"/>.
Solutions to the versioning requirements can be split into several
distinct areas. <xref target="I-D.verdt-netmod-yang-module-versioning"/>
is focused on YANG versioning scoped to individual modules. The overall
solution must also consider YANG versioning and conformance scoped to YANG
schema. YANG packages provide part of the solution for versioning YANG
schema.</t>
</section>
<section anchor="objectives" title="Objectives">
<t>The main goals of YANG package definitions include, but are
not restricted to:
<list style="symbols">
<t>To provide an alternative, simplified, YANG conformance mechanism.
Rather than conformance being performed against a set of individual YANG
module revisions, features, and deviations, conformance can be more
simply stated in terms of YANG packages, with a set of modifications
(e.g. additional modules, deviations, or features).</t>
<t>To allow YANG schema to be specified in a concise way rather than
having each server explicitly list all modules, revisions, and features.
YANG package definitions can be defined in documents that are available
offline, and accessible via a URL, rather than requiring explicit lists
of modules to be shared between client and server. Hence, a YANG
package must contain sufficient information to allow a client or server
to precisely construct the schema associated with the package.</t>
<t>To define a mainly linear versioned history of sets of modules
versions that are known to work together. I.e. to help mitigate the
problem where a client must manage devices from multiple vendors, and
vendor A implements version 1.0.0 of module foo and version 2.0.0 of
module bar, and vendor B implements version 2.0.0 of module foo and
version 1.0.0 of module bar. For a client, trying to interoperate with
multiple vendors, and many YANG modules, finding a consistent lowest
common denominator set of YANG module versions may be difficult, if not
impossible.</t>
</list>
</t>
<t>Protocol mechanisms of how clients can negotiate which packages or
package versions are to be used for NETCONF/RESTCONF communications are
outside the scope of this document, and are defined in <xref
target="I-D.wilton-netmod-yang-ver-selection"/>.</t>
<t>Finally, the package definitions proposed by this document are intended
to be relatively basic in their definition and the functionality that they
support. As industry gains experience using YANG packages, the standard
YANG mechanisms of updating, or augmenting, YANG modules could also be
used to extend the functionality supported by YANG packages, if
required.</t>
</section>
<section anchor="package" title="YANG Package Definition">
<t>This document specifies an approach to defining YANG packages that is
different to either of the approaches described in the background.</t>
<t>A YANG package is a versioned organizational structure defining a set of
related YANG modules, packages, features, and deviations. A YANG package
collectively defines a YANG schema.</t>
<t>Each YANG package has a name that SHOULD end with the suffix "-pkg".
Package names are normally expected to be globally unique, but in some
cases the package name may be locally scoped to a server or device, as
described in <xref target="package-scope"/>.</t>
<t>YANG packages are versioned using the same approaches described in
<xref target="I-D.verdt-netmod-yang-module-versioning"/> and <xref
target="I-D.verdt-netmod-yang-semver"/>. This is described in further
detail in <xref target="versioning"/>.</t>
<t>Each YANG package version, defines:
<list>
<t>some metadata about the package, e.g., description, tags, scoping,
referential completeness, location information.</t>
<t>a set of YANG modules, at particular revisions, that are implemented
by servers that implement the package. The modules may contain
deviations.</t>
<t>a set of import-only YANG modules, at particular revisions, that are
used 'import-only' by the servers that implement the package.</t>
<t>a set of included YANG packages, at particular revisions, that are also
implemented by servers that implement the package.</t>
<t>a set of YANG module features that must be supported by servers that
implement the package.</t>
</list>
</t>
<t>The structure for YANG package definitions uses existing YANG language
statements, YANG Data Structure Extensions <xref
target="I-D.ietf-netmod-yang-data-ext"/>, and YANG Instance Data File
Format <xref target="I-D.ietf-netmod-yang-instance-file-format"/>.</t>
<t>YANG package definitions are available offline in YANG Instance Data
Documents. Client applications can be designed to support particular
package versions that they expect to interoperate with.</t>
<t>YANG package definitions are available from the server, via
augmentations to YANG Library <xref target="RFC8525"/>. Rather than
client applications downloading the entire contents of YANG library to
confirm that the server schema is compatible with the client, they can
check, or download, a much shorter YANG package definition, and validate
that it conforms to the expected schema.</t>
<t>YANG package definitions can also be used to define the
schema associated with YANG instance data documents holding
other, e.g., non packages related, instance data.</t>
<section anchor="definition" title="Package definition rules">
<t>The following rules define how packages are defined:
<list>
<t>A YANG package MAY represent a complete YANG schema or only part of
a YANG schema with some module import dependencies missing, as
described in <xref target="completeness"/>.</t>
<t>Packages definitions are hierarchical. A package can include other
packages. Only a single version of a package can be included, and
conflicting package includes (e.g. from descendant package includes)
MUST be explicitly resolved by indicating which version takes
precedence, and which versions are being replaced.</t>
<t>For each module implemented by a package, only a single revision of
that module MUST be implemented. Multiple revisions of a module MAY
be listed as import-only dependencies.</t>
<t>The revision of a module listed in the package 'module' list
supersedes any 'implemented' revision of the module listed in an
included package module list. The 'replaces-revision' leaf-list is
used to indicate which 'implemented' or 'import-only' module revisions
are replaces by this module revision. This allows a package to
explicitly resolve conflicts between implemented module revisions in
included packages.</t>
<t>The 'replaces-revision' leaf-list in the 'import-only-module' list can
be used to exclude duplicate revisions of import-only modules from
included packages. Otherwise, the import-only-modules for a package
are the import-only-modules from all included packages combined with
any modules listed in the packages import-only-module list.</t>
</list>
</t>
</section>
<section anchor="versioning" title="Package versioning">
<t>Individual versions of a YANG package are versioned using
the "revision-label" scheme defined in section 3.3 of <xref
target="I-D.verdt-netmod-yang-module-versioning"/>.</t>
<section anchor="change_scope" title="Updating a package with a new version">
<t>Package compatibility is fundamentally defined by how the YANG schema
between two package versions has changed.</t>
<t>When a package definition is updated, the version associated with the
package MUST be updated appropriately, taking into consideration the
scope of the changes as defined by the rules below.</t>
<t>A package definition SHOULD define the previous version of the
package in the 'previous-version' leaf unless it is the initial version
of the package. If the 'previous-version' leaf is provided then the
package definition MUST set the 'nbc-changes' leaf if the new version is
non-backwards-compatible with respect to the package version defined in
the 'previous-version' leaf.</t>
<section anchor="nbc_package_change" title="Non-Backwards-compatible changes">
<t>The following changes classify as NBC changes to a package
definition:
<list>
<t>Changing an 'included-package' list entry to select a package
version that is non-backwards-compatible to the prior package
version, or removing a previously included package.</t>
<t>Changing a 'module' or 'import-only-module' list entry to
select a module revision that is non-backwards-compatible to the
prior module revision, or removing a previously implemented
module.</t>
<t>Removing a feature from the 'mandatory-feature' leaf-list.</t>
<t>Adding, changing, or removing a deviation that is considered a
non-backwards-compatible change to the affected data node in the
schema associated with the prior package version.</t>
</list>
</t>
</section>
<section anchor="bc_package_change" title="Backwards-compatible changes">
<t>The following changes classify as BC changes to a package
definition:
<list>
<t>Changing an 'included-package' list entry to select a package
version that is backwards-compatible to the prior package version,
or including a new package that does not conflict with any existing
included package or module.</t>
<t>Changing a 'module' or 'import-only-module' list entry to select
a module revision that is backwards-compatible to the prior module
revision, or including a new module to the package definition.</t>
<t>Adding a feature to the 'mandatory-feature' leaf-list.</t>
<t>Adding, changing, or removing a deviation that is considered a
backwards-compatible change to the affected data node in the schema
associated with the prior package version.</t>
</list>
</t>
</section>
<section anchor="editorial_package_change" title="Editorial changes">
<t>The following changes classify as editorial changes to a package
definition:
<list>
<t>Changing a 'included-package' list entry to select a package
version that is classified as an editorial change relative to the
prior package version.</t>
<t>Changing a 'module' or 'import-only-module' list entry to select
a module revision that is classified as an editorial change relative
to the prior module revision.</t>
<t>Any change to any metadata associated with a package definition
that causes it to have a different checksum value.</t>
</list>
</t>
</section>
</section>
<section anchor="semantic_versioning" title="YANG Semantic Versioning for packages">
<t>YANG Semantic Versioning <xref target="I-D.verdt-netmod-yang-semver"/> MAY be used as an appropriate type
of revision-label for the package version leaf.</t>
<t>If the format of the leaf matches the 'yangver:version' type
specified in ietf-yang-semver.yang, then the package version leaf MUST
be interpreted as a YANG semantic version number.</t>
<t>For YANG packages defined by the IETF, YANG semantic version numbers
MUST be used as the version scheme for YANG packages.</t>
<t>The rules for incrementing the YANG package version number
are equivalent to the semantic versioning rules used to
version individual YANG modules, defined in section 3.2 of
<xref target="I-D.verdt-netmod-yang-semver"/>, but use the
rules defined previously in <xref target="change_scope"/> to
determine whether a change is classified as
non-backwards-compatible, backwards-compatible, or editorial.
Where available, the semantic version number of the referenced
elements in the package (included packages or modules) can be
used to help determine the scope of changes being made.
</t>
</section>
<section title="Revision history">
<t>YANG packages do not contain a revision history. This is because
packages may have many revisions and a long revision history would bloat
the package definition. By recursively examining the 'previous-version'
leaf of a package definition, a full revision history (including where
non-backwards-compatible changes have occurred) can be dynamically
constructed, if all package versions are available.</t>
</section>
</section>
<section title="Package conformance">
<t>YANG packages allows for conformance to be checked at a package level
rather than requiring a client to download all modules, revisions, and
deviations from the server to ensure that the datastore schema used by the
server is compatible with the client.</t>
<t>YANG package conformance is analogous to how YANG <xref
target="RFC7950"/> requires that servers either implement a module
faithfully, or otherwise use deviations to indicate areas of
non-conformance.</t>
<t>For a top level package representing a datastore schema, servers MUST
implement the package definition faithfully, including all mandatory
features.</t>
<t>Package definitions MAY modify the schema for directly or
hierarchically included packages through the use of different module
revisions or module deviations. If the schema of any included package is
modified in a non-backwards-compatible way then it MUST be indicated by
setting the 'nbc-modified' leaf to true.</t>
<section title="Use of YANG semantic versioning">
<t>Using the YANG semantic versioning scheme for package version numbers
and module revision labels can help with conformance. In the general
case, clients should be able to determine the nature of changes between
two package versions by comparing the version number.</t>
<t>This usually means that a client does not have to be restricted to
working only with servers that advertise exactly the same version of a
package in YANG library. Instead, reasonable clients should be able to
interoperate with any server that supports a package version that is
backwards compatible to version that the client is designed for,
assuming that the client is designed to ignore operational values for
unknown data nodes.</t>
<t>For example, a client coded to support 'foo' package at version 1.0.0
should interoperate with a server implementing 'foo' package at version
1.3.5, because the YANG semantic versioning rules require that package
version 1.3.5 is backwards compatible to version 1.0.0.</t>
<t>This also has a relevance on servers that are capable of supporting
version selection because they need not support every version of a YANG
package to ensure good client compatibility. Choosing suitable minor
versions within each major version number should generally be
sufficient, particular if they can avoid NBC patch level changes
(i.e. 'M' labeled versions).</t>
</section>
<section anchor="checksums" title="Package checksums">
<t>Each YANG package definition may have a checksum associated with it
to allow a client to validate that the package definition of the server
matches the expected package definition without downloading the full
package definition from the server.</t>
<t>The checksum for a package is calculated using the SHA-256 hash (XXX,
reference) of the full file contents of the YANG package instance data
file. This means that the checksum includes all whitespace and
formatting, encoding, and all meta-data fields associated with the
package and the instance data document).</t>
<t>The checksum for a module is calculated using the SHA-256 hash of the
YANG module file definition. This means that the checksum includes all
whitespace, formatting, and comments within the YANG module.</t>
<t>Packages that are locally scoped to a server may not have an offline
instance data document available, and hence MAY not have a checksum.</t>
<t>The package definition allows URLs and checksums to be specified for
all included packages, modules and submodules within the package
definition. Checksums SHOULD be included in package definitions to
validate the full integrity of the package.</t>
<t>On a server, package checksums SHOULD also be provided for the top
level packages associated with the datastore schema.</t>
</section>
<section anchor="rel_with_datastores" title="The relationship between packages and datastores">
<t>As defined by NMDA <xref target="RFC8342"/>, each datastore has an
associated datastore schema. Sections 5.1 and 5.3 of NMDA defines
further constraints on the schema associated with datastores. These
constraints can be summarized thus:
<list>
<t>The schema for all conventional datastores is the same.</t>
<t>The schema for non conventional configuration datastores (e.g.,
dynamic datastores) may completely differ (i.e. no overlap at all)
from the schema associated with the conventional configuration
datastores, or may partially or fully overlap with the schema of the
conventional configuration datastores. A dynamic datastore, for
example, may support different modules than conventional datastores,
or may support a subset or superset of modules, features, or data nodes
supported in the conventional configuration datastores. Where a data
node exists in multiple datastore schema it has the same type,
properties and semantics.</t>
<t>The schema for the operational datastore is intended to be a
superset of all the configuration datastores (i.e. includes all the
schema nodes from the conventional configuration datastores), but data
nodes can be omitted if they cannot be accurately reported. The
operational datastore schema can include additional modules containing
only config false data nodes, but there is no harm in including those
modules in the configuration datastore schema as well.</t>
</list>
</t>
<t>Given that YANG packages represent a YANG schema, it follows that
each datastore schema can be represented using packages. In addition,
the schema for most datastores on a server are often closely related.
Given that there are many ways that a datastore schema could be
represented using packages, the following guidance provides a consistent
approach to help clients understand the relationship between the
different datastore schema supported by a device (e.g., which parts of
the schema are common and which parts have differences):
<list>
<t>Any datastores (e.g., conventional configuration datastores) that
have exactly the same datastore schema MUST use the same package
definitions. This is to avoid, for example, the creation of a
'running-cfg' package and a separate 'intended-cfg' package that have
identical schema.</t>
<t>Common package definitions SHOULD be used for those parts of the
datastore schema that are common between datastores, when those
datastores do not share exactly the same datastore schema. E.g., if a
substantial part of the schema is common between the conventional,
dynamic, and operational datastores then a single common package can
be used to describe the common parts, along with other packages to
describe the unique parts of each datastore schema.</t>
<t>YANG modules that do not contain any configuration data nodes SHOULD
be included in the package for configuration datastores if that helps
unify the package definitions.</t>
<t>The packages for the operational datastore schema MUST include all
packages for all configuration datastores, along with any required
modules defining deviations to mark unsupported data nodes. The
deviations MAY be defined directly in the packages defining the
operational datastore schema, or in separate non referentially
complete packages.</t>
<t>The schema for a datastore MAY be represented using a single
package or as the union of a set of compatible packages, i.e.,
equivalently to a set of non-conflicting packages being included
together in an overarching package definition.</t>
</list>
</t>
</section>
</section>
<section anchor="completeness" title="Schema referential completeness">
<t>A YANG package may represent a schema that is 'referentially complete',
or 'referentially incomplete', indicated in the package definition by the
'complete' flag.</t>
<t>If all import statements in all YANG modules included in the package
(either directly, or through included packages) can be resolved to a
module revision defined with the YANG package definition, then the package
is classified as referentially complete. Conversely, if one or more
import statements cannot be resolved to a module specified as part of the
package definition, then the package is classified as referentially
incomplete.</t>
<t>A package that represents the exact contents of a datastore schema MUST
always be referentially complete.</t>
<t>Referentially incomplete packages can be used, along with locally
scoped packages, to represent an update to a device's datastore schema as
part of an optional software hot fix. E.g., the base software is made
available as a complete globally scoped package. The hot fix is made
available as an incomplete globally scoped package. A device's datastore
schema can define a local package that implements the base software
package updated with the hot fix package.</t>
<t>Referentially incomplete packages could also be used to group sets of
logically related modules together, but without requiring a fixed
dependency on all imported 'types' modules (e.g., iana-if-types.yang),
instead leaving the choice of specific revisions of 'types' modules to be
resolved when the package definition is used.</t>
</section>
<section anchor="package-scope" title="Package name scoping and uniqueness">
<t>YANG package names can be globally unique, or locally scoped to a
particular server or device.</t>
<section title="Globally scoped packages">
<t>The name given to a package MUST be globally unique, and it MUST
include an appropriate organization prefix in the name, equivalent to
YANG module naming conventions.</t>
<t>Ideally a YANG instance data document defining a particular package
version would be publicly available at one or more URLs.</t>
</section>
<section title="Server scoped packages">
<t>Package definitions may be scoped to a particular server by setting
the 'is-local' leaf to true in the package definition.</t>
<t>Locally scoped packages MAY have a package name that is not globally
unique.</t>
<t>Locally scoped packages MAY have a definition that is not available
offline from the server in a YANG instance data document.</t>
</section>
</section>
<section title="Submodules packages considerations">
<t>As defined in <xref target="RFC7950"/> and <xref
target="I-D.verdt-netmod-yang-semver"/>, YANG conformance and versioning
is specified in terms of particular revisions of YANG modules rather than
for individual submodules.</t>
<t>However, YANG package definitions also include the list of submodules
included by a module, primarily to provide a location of where the
submodule definition can be obtained from, allowing a YANG schema to be
fully constructed from a YANG package instance-data file definition.</t>
</section>
<section title="Package tags">
<t><xref target="I-D.ietf-netmod-module-tags"/> defines YANG
module tags as a mechanism to annotate a module definition with
additional metadata. Tags MAY also be associated to a package
definition via the 'tags' leaf-list. The tags use the same
registry and definitions used by YANG module tags.</t>
</section>
<section title="YANG package core definition">
<t>The ietf-yang-package-types.yang module defines a grouping to specify the
core elements of the YANG package structure that is used within YANG package
instance data documents (ietf-yang-package-instance.yang) and also on the
server (ietf-yang-packages.yang).</t>
<figure>
<preamble>The "ietf-yang-package-types" YANG module has the following structure:</preamble>
<artwork>
<![CDATA[
module: ietf-yang-package-types
grouping yang-pkg-identification-leafs
+-- name pkg-name
+-- version pkg-version
grouping yang-pkg-instance
+-- name pkg-name
+-- version pkg-version
+-- timestamp? yang:date-and-time
+-- organization? string
+-- contact? string
+-- description? string
+-- reference? string
+-- complete? boolean
+-- local? boolean
+-- previous-version? pkg-version
+-- nbc-changes? boolean
+-- tag* tags:tag
+-- mandatory-feature* scoped-feature
+-- included-package* [name version]
| +-- name pkg-name
| +-- version pkg-version
| +-- replaces-version* pkg-version
| +-- nbc-modified? boolean
| +-- location* inet:uri
| +-- checksum? pkg-types:sha-256-hash
+-- module* [name]
| +-- name yang:yang-identifier
| +-- revision? rev:revision-date-or-label
| +-- replaces-revision* rev:revision-date-or-label
| +-- namespace? inet:uri
| +-- location* inet:uri
| +-- checksum? pkg-types:sha-256-hash
| +-- submodule* [name]
| +-- name? yang:yang-identifier
| +-- revision yang:revision-identifier
| +-- location* inet:uri
| +-- checksum? pkg-types:sha-256-hash
+-- import-only-module* [name revision]
+-- name? yang:yang-identifier
+-- revision? rev:revision-date-or-label
+-- replaces-revision* rev:revision-date-or-label
+-- namespace? inet:uri
+-- location* inet:uri
+-- checksum? pkg-types:sha-256-hash
+-- submodule* [name]
+-- name? yang:yang-identifier
+-- revision yang:revision-identifier
+-- location* inet:uri
+-- checksum? pkg-types:sha-256-hash
]]>
</artwork>
</figure>
</section>
</section>
<section title="Package Instance Data Documents">
<t>YANG packages SHOULD be available offline from the server,
defined as YANG instance data documents <xref
target="I-D.ietf-netmod-yang-instance-file-format"/> using the
YANG schema below to define the package data.</t>
<t>The format of the YANG package instance file MUST follow the following rules:
<list>
<t>The file SHOULD be encoded in JSON.</t>
<t>The name of the file SHOULD follow the format
"<package-name>@<version>.json".</t>
<t>The package name MUST be specified in both the
instance-data-set 'name' and package 'name' leafs.</t>
<t>The 'description' field of the instance-data-set SHOULD be
"YANG package definition".</t>
<t>The 'timestamp', "organization', 'contact' fields are defined
in both the instance-data-set metadata and the YANG package
metadata. Package definitions SHOULD only define these fields
as part of the package definition. If any of these fields are
populated in the instance-data-set metadata then they MUST
contain the same value as the corresponding leaves in the
package definition.</t>
<t>The 'revision' list in the instance data document SHOULD NOT
be used, since versioning is handled by the package
definition.</t>
<t>The instance data document for each version of a YANG package
SHOULD be made available at one of more locations accessible via
URLs. If one of the listed locations defines a definitive
reference implementation for the package definition then it MUST
be listed as the first entry in the list.</t>
</list>
</t>
<figure>
<preamble>The "ietf-yang-package" YANG module has the following structure:</preamble>
<artwork>
<![CDATA[
module: ietf-yang-package
structure package:
// Uses the yang-package-instance grouping defined in
// ietf-yang-package-types.yang
+-- name pkg-name
+-- version pkg-version
... remainder of yang-package-instance grouping ...
]]>
</artwork>
</figure>
</section>
<section title="Package Definitions on a Server">
<section title="Package List">
<t>A top level 'packages' container holds the list of all
versions of all packages known to the server. Each list entry
uses the common package definition, but with the addition of
package location and checksum information that cannot be
contained within a offline package definition contained in an
instance data document.</t>
<t>The '/packages/package' list MAY include multiple versions of a
particular package. E.g. if the server is capable of allowing clients
to select which package versions should be used by the server.</t>
<t></t>
</section>
<section title="Tree diagram">
<figure>
<preamble>The "ietf-yang-packages" YANG module has the following structure:</preamble>
<artwork>
<![CDATA[
module: ietf-yang-packages
+--ro packages
+--ro package* [name version]
// Uses the yang-package-instance grouping defined in
// ietf-yang-package-types.yang, with location and checksum:
+--ro name pkg-name
+--ro version pkg-version
... remainder of yang-package-instance grouping ...
+--ro location* inet:uri
+--ro checksum? pkg-types:sha-256-hash
]]>
</artwork>
</figure>
</section>
</section>
<section title = "YANG Library Package Bindings">
<t>The YANG packages module also augments YANG library to allow a server
to optionally indicate that a datastore schema is defined by a package, or
a union of compatible packages. Since packages can generally be made
available offline in instance data documents, it may be sufficient for a
client to only check that a compatible version of the package is
implemented by the server without fetching either the package definition,
or downloading and comparing the full list of modules and enabled
features.</t>
<t>If a server indicates that a datastore schema maps to a particular
package, then it MUST exactly match the schema defined by that package,
taking into account enabled features and any deviations.</t>
<t>If a server cannot faithfully implement a package then it can define a
new package to accurately report what it does implement. The new package
can include the original package as an included package, and the new
package can define additional modules containing deviations to the modules
in the original package, allowing the new package to accurately describe
the server's behavior. There is no specific mechanism provided to
indicate that a mandatory-feature in package definition is not supported
on a server, but deviations MAY be used to disable functionality
predicated by an if-feature statement.</t>
<figure>
<preamble>The "ietf-yl-packages" YANG module has the following structure:</preamble>
<artwork>
<![CDATA[
module: ietf-yl-packages
augment /yanglib:yang-library/yanglib:schema:
+--ro package* [name version]
+--ro name -> /pkgs:packages/package/name
+--ro version leafref
+--ro checksum? leafref
]]>
</artwork>
</figure>
</section>
<section title="YANG packages as schema for YANG instance data document">
<t>YANG package definitions can be used as the schema definition for YANG
instance data documents. When using a package schema, the name and
version of the package MUST be specified, a package checksum and/or URL to
the package definition MAY also be provided.</t>
<figure>
<preamble>The "ietf-yang-inst-data-pkg" YANG module has the following structure:</preamble>
<artwork>
<![CDATA[
module: ietf-yang-inst-data-pkg
augment-structure /yid:instance-data-set/yid:content-schema-spec:
+--:(pkg-schema)
+-- pkg-schema
+-- name pkg-name
+-- version pkg-version
+-- location* inet:uri
+-- checksum? pkg-types:sha-256-hash
]]>
</artwork>
</figure>
</section>
<section title="YANG Modules">
<t>The YANG module definitions for the modules described in the previous sections.</t>
<figure>
<artwork>
<![CDATA[
<CODE BEGINS> file "ietf-yang-package-types@2020-01-21.yang"
module ietf-yang-package-types {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-yang-package-types";
prefix "pkg-types";
import ietf-yang-revisions {
prefix rev;
reference "XXXX: Updated YANG Module Revision Handling";
}
import ietf-yang-types {
prefix yang;
rev:revision-or-derived 2019-07-21;
reference "RFC 6991bis: Common YANG Data Types.";
}
import ietf-inet-types {
prefix inet;
rev:revision-or-derived 2013-07-15;
reference "RFC 6991: Common YANG Data Types.";
}
import ietf-module-tags {
prefix tags;
// RFC Ed. Fix revision once revision date of
// ietf-module-tags.yang is known.
reference "RFC XXX: YANG Module Tags.";
}
organization
"IETF NETMOD (Network Modeling) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org>
Author: Rob Wilton
<mailto:rwilton@cisco.com>";
description
"This module provides type and grouping definitions for YANG
packages.
Copyright (c) 2019 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.";
// RFC Ed.: update the date below with the date of RFC publication
// and remove this note.
// RFC Ed.: replace XXXX with actual RFC number and remove this
// note.
revision 2020-01-21 {
rev:revision-label 0.2.0;
description
"Initial revision";
reference
"RFC XXXX: YANG Packages";
}
/*
* Typedefs
*/
typedef pkg-name {
type yang:yang-identifier;
description
"Package names are typed as YANG identifiers.";
}
typedef pkg-version {
type rev:revision-date-or-label;
description
"Package versions SHOULD be a revision-label (e.g. perhaps a
YANG Semver version string). Package versions MAY also be a
revision-date";
}
typedef pkg-identifier {
type rev:name-revision;
description
"Package identifiers combine a pkg-name and a pkg-version";
}
typedef scoped-feature {
type string {
pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*:[a-zA-Z_][a-zA-Z0-9\-_.]*';
}
description
"Represents a feature name scoped to a particular module,
identified as the '<module-name>:<feature-name>', where both
<module-name> and <feature-name> are YANG identifier strings,
as defiend by Section 12 or RFC 6020.";
reference
"RFC XXXX, YANG Packages.";
}
typedef sha-256-hash {
type string {
length "64";
pattern "[0-9a-fA-F]*";
}
description
"A SHA-256 hash represented as a hexadecimal string.
Used as the checksum for modules, submodules and packages in a
YANG package definition.
For modules and submodules the SHA-256 hash is calculated on
the contents of the YANG file defining the module/submodule.
For packages the SHA-256 hash is calculated on the file
containing the YANG instance data document holding the package
definition";
}
/*
* Groupings
*/
grouping yang-pkg-identification-leafs {
description
"Parameters for identifying a specific version of a YANG
package";
leaf name {
type pkg-name;
mandatory true;
description
"The YANG package name.";
}
leaf version {
type pkg-version;
mandatory true;
description
"Uniquely identies a particular version of a YANG package.
Follows the definition for revision labels defined in
draft-verdt-nemod-yang-module-versioning, section XXX";
}
}
grouping yang-pkg-instance {
description
"Specifies the data node for a full YANG package instance
represented either on a server or as a YANG instance data
document.";
uses yang-pkg-identification-leafs;
leaf timestamp {
type yang:date-and-time;
description
"An optional timestamp for when this package was created.
This does not need to be unique across all versions of a
package.";
}
leaf organization {
type string;
description "Organization responsible for this package";
}
leaf contact {
type string;
description
"Contact information for the person or organization to whom
queries concerning this package should be sent.";
}
leaf description {
type string;
description "Provides a description of the package";
}
leaf reference {
type string;
description "Allows for a reference for the package";