draft-ietf-netmod-yang-packages-01.txt   draft-ietf-netmod-yang-packages-02.txt 
Network Working Group R. Wilton, Ed. Network Working Group R. Wilton, Ed.
Internet-Draft R. Rahman Internet-Draft R. Rahman
Intended status: Standards Track J. Clarke Intended status: Standards Track J. Clarke
Expires: May 6, 2021 Cisco Systems, Inc. Expires: 28 April 2022 Cisco Systems, Inc.
J. Sterne J. Sterne
Nokia Nokia
B. Wu, Ed. B. Wu, Ed.
Huawei Huawei
November 2, 2020 25 October 2021
YANG Packages YANG Packages
draft-ietf-netmod-yang-packages-01 draft-ietf-netmod-yang-packages-02
Abstract Abstract
This document defines YANG packages, a versioned organizational This document defines YANG packages, a versioned organizational
structure holding a set of related YANG modules that collectively structure holding a set of related YANG modules that collectively
define a YANG schema. It describes how packages: are represented on define a YANG schema. It describes how packages: are represented on
a server, can be defined in offline YANG instance data files, and can a server, can be defined in offline YANG instance data files, and can
be used to define the schema associated with YANG instance data be used to define the schema associated with YANG instance data
files. files.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 6, 2021. This Internet-Draft will expire on 28 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect Please review these documents carefully, as they describe your rights
to this document. Code Components extracted from this document must and restrictions with respect to this document. Code Components
include Simplified BSD License text as described in Section 4.e of extracted from this document must include Simplified BSD License text
the Trust Legal Provisions and are provided without warranty as as described in Section 4.e of the Trust Legal Provisions and are
described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Background on YANG packages . . . . . . . . . . . . . . . . . 4 3. Background on YANG packages . . . . . . . . . . . . . . . . . 4
4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. YANG Package Definition . . . . . . . . . . . . . . . . . . . 6 5. YANG Package Definition . . . . . . . . . . . . . . . . . . . 6
5.1. Package definition rules . . . . . . . . . . . . . . . . 7 5.1. Package definition rules . . . . . . . . . . . . . . . . 7
5.2. Package versioning . . . . . . . . . . . . . . . . . . . 8 5.2. Package versioning . . . . . . . . . . . . . . . . . . . 8
5.2.1. Updating a package with a new version . . . . . . . . 8 5.2.1. Updating a package with a new version . . . . . . . . 8
5.2.1.1. Non-Backwards-compatible changes . . . . . . . . 8 5.2.1.1. Non-Backwards-compatible changes . . . . . . . . 8
5.2.1.2. Backwards-compatible changes . . . . . . . . . . 9 5.2.1.2. Backwards-compatible changes . . . . . . . . . . 9
5.2.1.3. Editorial changes . . . . . . . . . . . . . . . . 9 5.2.1.3. Editorial changes . . . . . . . . . . . . . . . . 9
5.2.2. YANG Semantic Versioning for packages . . . . . . . . 9 5.2.2. YANG Semantic Versioning for packages . . . . . . . . 9
5.2.3. Revision history . . . . . . . . . . . . . . . . . . 10 5.2.3. Revision history . . . . . . . . . . . . . . . . . . 10
5.3. Package conformance . . . . . . . . . . . . . . . . . . . 10 5.3. Package conformance . . . . . . . . . . . . . . . . . . . 10
5.3.1. Use of YANG semantic versioning . . . . . . . . . . . 10 5.3.1. Use of YANG semantic versioning . . . . . . . . . . . 10
5.3.2. Package checksums . . . . . . . . . . . . . . . . . . 11 5.3.2. The relationship between packages and datastores . . 11
5.3.3. The relationship between packages and datastores . . 12 5.4. Schema referential completeness . . . . . . . . . . . . . 12
5.4. Schema referential completeness . . . . . . . . . . . . . 13 5.5. Package name scoping and uniqueness . . . . . . . . . . . 13
5.5. Package name scoping and uniqueness . . . . . . . . . . . 14 5.5.1. Globally scoped packages . . . . . . . . . . . . . . 13
5.5.1. Globally scoped packages . . . . . . . . . . . . . . 14 5.5.2. Server scoped packages . . . . . . . . . . . . . . . 13
5.5.2. Server scoped packages . . . . . . . . . . . . . . . 14
5.6. Submodules packages considerations . . . . . . . . . . . 14 5.6. Submodules packages considerations . . . . . . . . . . . 14
5.7. Package tags . . . . . . . . . . . . . . . . . . . . . . 14 5.7. Package tags . . . . . . . . . . . . . . . . . . . . . . 14
5.8. YANG Package Usage Guidance . . . . . . . . . . . . . . . 15 5.8. YANG Package Usage Guidance . . . . . . . . . . . . . . . 14
5.8.1. Use of deviations in YANG packages . . . . . . . . . 15 5.8.1. Use of deviations in YANG packages . . . . . . . . . 14
5.8.2. Use of features in YANG modules and YANG packages . . 16 5.8.2. Use of features in YANG modules and YANG packages . . 15
5.9. YANG package core definition . . . . . . . . . . . . . . 16 5.9. YANG package core definition . . . . . . . . . . . . . . 15
6. Package Instance Data Files . . . . . . . . . . . . . . . . . 17 6. Package Instance Data Files . . . . . . . . . . . . . . . . . 16
7. Package Definitions on a Server . . . . . . . . . . . . . . . 18 7. Package Definitions on a Server . . . . . . . . . . . . . . . 17
7.1. Package List . . . . . . . . . . . . . . . . . . . . . . 18 7.1. Package List . . . . . . . . . . . . . . . . . . . . . . 18
7.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 19 7.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 18
8. YANG Library Package Bindings . . . . . . . . . . . . . . . . 19 8. YANG Library Package Bindings . . . . . . . . . . . . . . . . 18
9. YANG packages as schema for YANG instance data document . . . 20 9. YANG packages as schema for YANG instance data document . . . 19
10. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 20 10. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 19
11. Security Considerations . . . . . . . . . . . . . . . . . . . 41 11. Security Considerations . . . . . . . . . . . . . . . . . . . 39
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
13. Open Questions/Issues . . . . . . . . . . . . . . . . . . . . 44 13. Open Questions/Issues . . . . . . . . . . . . . . . . . . . . 41
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
15.1. Normative References . . . . . . . . . . . . . . . . . . 44 15.1. Normative References . . . . . . . . . . . . . . . . . . 41
15.2. Informative References . . . . . . . . . . . . . . . . . 46 15.2. Informative References . . . . . . . . . . . . . . . . . 44
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 46
A.1. Example IETF Network Device YANG package . . . . . . . . 47 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 44
A.2. Example IETF Basic Routing YANG package . . . . . . . . . 49 A.1. Example IETF Network Device YANG package . . . . . . . . 45
A.3. Package import conflict resolution example . . . . . . . 52 A.2. Example IETF Basic Routing YANG package . . . . . . . . . 47
Appendix B. Possible alternative solutions . . . . . . . . . . . 55 A.3. Package import conflict resolution example . . . . . . . 50
B.1. Using module tags . . . . . . . . . . . . . . . . . . . . 55 Appendix B. Possible alternative solutions . . . . . . . . . . . 52
B.2. Using YANG library . . . . . . . . . . . . . . . . . . . 56 B.1. Using module tags . . . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 B.2. Using YANG library . . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53
1. Terminology and Conventions 1. Terminology and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This document uses terminology introduced in the YANG versioning This document uses terminology introduced in the YANG versioning
requirements draft [I-D.ietf-netmod-yang-versioning-reqs]. requirements draft [I-D.ietf-netmod-yang-versioning-reqs].
This document also makes of the following terminology introduced in This document also makes of the following terminology introduced in
the Network Management Datastore Architecture [RFC8342]: the Network Management Datastore Architecture [RFC8342]:
o datastore schema * datastore schema
This document also makes of the following terminology introduced in This document also makes of the following terminology introduced in
the YANG 1.1 Data Modeling Language [RFC7950]: the YANG 1.1 Data Modeling Language [RFC7950]:
o data node * data node
In addition, this document defines the following terminology: In addition, this document defines the following terminology:
o YANG schema: A datastore schema, not bound to any particular * YANG schema: A datastore schema, not bound to any particular
datastore. datastore.
o YANG package: An organizational structure containing a collection * YANG package: An organizational structure containing a collection
of YANG modules, normally defined in a YANG instance data file. A of YANG modules, normally defined in a YANG instance data file. A
YANG package defines a YANG schema by specifying a set of YANG YANG package defines a YANG schema by specifying a set of YANG
modules and their revisions, other packages and their revisions, modules and their revisions, other packages and their revisions,
mandatory features, and deviations. YANG packages are defined in mandatory features, and deviations. YANG packages are defined in
Section 5. Section 5.
o backwards-compatible (BC) change: When used in the context of a * backwards-compatible (BC) change: When used in the context of a
YANG module, it follows the definition in Section 3.1.1 of YANG module, it follows the definition in Section 3.1.1 of
[I-D.ietf-netmod-yang-module-versioning]. When used in the [I-D.ietf-netmod-yang-module-versioning]. When used in the
context of a YANG package, it follows the definition in context of a YANG package, it follows the definition in
Section 5.2.1.2. Section 5.2.1.2.
o non-backwards-compatible (NBC) change: When used in the context of * non-backwards-compatible (NBC) change: When used in the context of
a YANG module, it follows the definition in Section 3.1.2 of a YANG module, it follows the definition in Section 3.1.2 of
[I-D.ietf-netmod-yang-module-versioning]. When used in the [I-D.ietf-netmod-yang-module-versioning]. When used in the
context of a YANG package, it follows the definition in context of a YANG package, it follows the definition in
Section 5.2.1.2. Section 5.2.1.2.
o editorial change: When used in the context of a YANG module, it * editorial change: When used in the context of a YANG module, it
follows the definition of an 'editorial change' in 3.2 of follows the definition of an 'editorial change' in 3.2 of
[I-D.ietf-netmod-yang-module-versioning]. When used in the [I-D.ietf-netmod-yang-module-versioning]. When used in the
context of a YANG package, it follows the definition in context of a YANG package, it follows the definition in
Section 5.2.1.3. Section 5.2.1.3.
2. Introduction 2. Introduction
This document defines and describes the YANG [RFC7950] constructs This document defines and describes the YANG [RFC7950] constructs
that are used to define and use YANG packages. that are used to define and use YANG packages.
skipping to change at page 5, line 18 skipping to change at page 5, line 16
versioning scoped to individual modules. The overall solution must versioning scoped to individual modules. The overall solution must
also consider YANG versioning and conformance scoped to YANG schema. also consider YANG versioning and conformance scoped to YANG schema.
YANG packages provide part of the solution for versioning YANG YANG packages provide part of the solution for versioning YANG
schema. schema.
4. Objectives 4. Objectives
The main goals of YANG package definitions include, but are not The main goals of YANG package definitions include, but are not
restricted to: restricted to:
o To provide an alternative, simplified, YANG conformance mechanism. * To provide an alternative, simplified, YANG conformance mechanism.
Rather than conformance being performed against a set of Rather than conformance being performed against a set of
individual YANG module revisions, features, and deviations, individual YANG module revisions, features, and deviations,
conformance can be more simply stated in terms of YANG packages, conformance can be more simply stated in terms of YANG packages,
with a set of modifications (e.g. additional modules, deviations, with a set of modifications (e.g. additional modules, deviations,
or features). or features).
o To allow YANG schema to be specified in a concise way rather than * To allow YANG schema to be specified in a concise way rather than
having each server explicitly list all modules, revisions, and having each server explicitly list all modules, revisions, and
features. YANG package definitions can be defined in documents features. YANG package definitions can be defined in documents
that are available offline, and accessible via a URL, rather than that are available offline, and accessible via a URL, rather than
requiring explicit lists of modules to be shared between client requiring explicit lists of modules to be shared between client
and server. Hence, a YANG package must contain sufficient and server. Hence, a YANG package must contain sufficient
information to allow a client or server to precisely construct the information to allow a client or server to precisely construct the
schema associated with the package. schema associated with the package.
o To define a mainly linear versioned history of sets of modules * To define a mainly linear versioned history of sets of modules
versions that are known to work together. I.e. to help mitigate versions that are known to work together. I.e. to help mitigate
the problem where a client must manage devices from multiple the problem where a client must manage devices from multiple
vendors, and vendor A implements version 1.0.0 of module foo and 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 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, of module foo and version 1.0.0 of module bar. For a client,
trying to interoperate with multiple vendors, and many YANG trying to interoperate with multiple vendors, and many YANG
modules, finding a consistent lowest common denominator set of modules, finding a consistent lowest common denominator set of
YANG module versions may be difficult, if not impossible. YANG module versions may be difficult, if not impossible.
Protocol mechanisms of how clients can negotiate which packages or Protocol mechanisms of how clients can negotiate which packages or
skipping to change at page 6, line 29 skipping to change at page 6, line 26
some cases the package name may be locally scoped to a server or some cases the package name may be locally scoped to a server or
device, as described in Section 5.5. device, as described in Section 5.5.
YANG packages are versioned using the same approaches described in YANG packages are versioned using the same approaches described in
[I-D.ietf-netmod-yang-module-versioning] and [I-D.ietf-netmod-yang-module-versioning] and
[I-D.ietf-netmod-yang-semver]. This is described in further detail [I-D.ietf-netmod-yang-semver]. This is described in further detail
in Section 5.2. in Section 5.2.
Each YANG package version, defines: Each YANG package version, defines:
o some metadata about the package, e.g., description, tags, scoping, * some metadata about the package, e.g., description, tags, scoping,
referential completeness, location information. referential completeness, location information.
o a set of YANG modules, at particular revisions, that are * a set of YANG modules, at particular revisions, that are
implemented by servers that implement the package. The modules implemented by servers that implement the package. The modules
may contain deviations. may contain deviations.
o a set of import-only YANG modules, at particular revisions, that * a set of import-only YANG modules, at particular revisions, that
are used 'import-only' by the servers that implement the package. are used 'import-only' by the servers that implement the package.
o a set of included YANG packages, at particular revisions, that are * a set of included YANG packages, at particular revisions, that are
also implemented by servers that implement the package. also implemented by servers that implement the package.
o a set of YANG module features that must be supported by servers * a set of YANG module features that must be supported by servers
that implement the package. that implement the package.
The structure for YANG package definitions uses existing YANG The structure for YANG package definitions uses existing YANG
language statements, YANG Data Structure Extensions language statements, YANG Data Structure Extensions
[I-D.ietf-netmod-yang-data-ext], and YANG Instance Data File Format [I-D.ietf-netmod-yang-data-ext], and YANG Instance Data File Format
[I-D.ietf-netmod-yang-instance-file-format]. [I-D.ietf-netmod-yang-instance-file-format].
YANG package definitions are available offline in YANG instance data YANG package definitions are available offline in YANG instance data
files. Client applications can be designed to support particular files. Client applications can be designed to support particular
package versions that they expect to interoperate with. package versions that they expect to interoperate with.
skipping to change at page 8, line 40 skipping to change at page 8, line 35
version of the package. If the 'previous-version' leaf is provided version of the package. If the 'previous-version' leaf is provided
then the package definition MUST set the 'nbc-changes' leaf if the then the package definition MUST set the 'nbc-changes' leaf if the
new version is non-backwards-compatible with respect to the package new version is non-backwards-compatible with respect to the package
version defined in the 'previous-version' leaf. version defined in the 'previous-version' leaf.
5.2.1.1. Non-Backwards-compatible changes 5.2.1.1. Non-Backwards-compatible changes
The following changes classify as non-backwards-compatible changes to The following changes classify as non-backwards-compatible changes to
a package definition: a package definition:
o Changing an 'included-package' list entry to select a package * Changing an 'included-package' list entry to select a package
version that is non-backwards-compatible to the prior package version that is non-backwards-compatible to the prior package
version, or removing a previously included package. version, or removing a previously included package.
o Changing a 'module' or 'import-only-module' list entry to select a * Changing a 'module' or 'import-only-module' list entry to select a
module revision that is non-backwards-compatible to the prior module revision that is non-backwards-compatible to the prior
module revision, or removing a previously implemented module. module revision, or removing a previously implemented module.
o Removing a feature from the 'mandatory-feature' leaf-list. * Removing a feature from the 'mandatory-feature' leaf-list.
o Adding, changing, or removing a deviation that is considered a * Adding, changing, or removing a deviation that is considered a
non-backwards-compatible change to the affected data node in the non-backwards-compatible change to the affected data node in the
schema associated with the prior package version. schema associated with the prior package version.
5.2.1.2. Backwards-compatible changes 5.2.1.2. Backwards-compatible changes
The following changes classify as backwards-compatible changes to a The following changes classify as backwards-compatible changes to a
package definition: package definition:
o Changing an 'included-package' list entry to select a package * Changing an 'included-package' list entry to select a package
version that is backwards-compatible to the prior package version, version that is backwards-compatible to the prior package version,
or including a new package that does not conflict with any or including a new package that does not conflict with any
existing included package or module. existing included package or module.
o Changing a 'module' or 'import-only-module' list entry to select a * Changing a 'module' or 'import-only-module' list entry to select a
module revision that is backwards-compatible to the prior module module revision that is backwards-compatible to the prior module
revision, or including a new module to the package definition. revision, or including a new module to the package definition.
o Adding a feature to the 'mandatory-feature' leaf-list. * Adding a feature to the 'mandatory-feature' leaf-list.
o Adding, changing, or removing a deviation that is considered a * Adding, changing, or removing a deviation that is considered a
backwards-compatible change to the affected data node in the backwards-compatible change to the affected data node in the
schema associated with the prior package version. schema associated with the prior package version.
5.2.1.3. Editorial changes 5.2.1.3. Editorial changes
The following changes classify as editorial changes to a package The following changes classify as editorial changes to a package
definition: definition:
o Changing a 'included-package' list entry to select a package * Changing a 'included-package' list entry to select a package
version that is classified as an editorial change relative to the version that is classified as an editorial change relative to the
prior package version. prior package version.
o Changing a 'module' or 'import-only-module' list entry to select a * Changing a 'module' or 'import-only-module' list entry to select a
module revision that is classified as an editorial change relative module revision that is classified as an editorial change relative
to the prior module revision. to the prior module revision.
o Any change to any metadata associated with a package definition * Any change to any metadata associated with a package definition.
that causes it to have a different checksum value.
5.2.2. YANG Semantic Versioning for packages 5.2.2. YANG Semantic Versioning for packages
YANG Semantic Versioning [I-D.ietf-netmod-yang-semver] MAY be used as YANG Semantic Versioning [I-D.ietf-netmod-yang-semver] MAY be used as
an appropriate type of revision-label for the package version leaf. an appropriate type of revision-label for the package version leaf.
If the format of the leaf matches the 'yangver:version' type If the format of the leaf matches the 'yangver:version' type
specified in ietf-yang-semver.yang, then the package version leaf specified in ietf-yang-semver.yang, then the package version leaf
MUST be interpreted as a YANG semantic version number. MUST be interpreted as a YANG semantic version number.
skipping to change at page 11, line 25 skipping to change at page 11, line 25
version 1.3.5, because the YANG semantic versioning rules require 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. that package version 1.3.5 is backwards compatible to version 1.0.0.
This also has a relevance on servers that are capable of supporting This also has a relevance on servers that are capable of supporting
version selection because they need not support every version of a version selection because they need not support every version of a
YANG package to ensure good client compatibility. Choosing suitable YANG package to ensure good client compatibility. Choosing suitable
minor versions within each major version number should generally be minor versions within each major version number should generally be
sufficient, particular if they can avoid non-backwards-compatible sufficient, particular if they can avoid non-backwards-compatible
patch level changes. patch level changes.
5.3.2. Package checksums 5.3.2. The relationship between packages and datastores
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.
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 file).
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.
Packages that are locally scoped to a server may not have an offline
instance data file available, and hence MAY not have a checksum.
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.
On a server, package checksums SHOULD also be provided for the top
level packages associated with the datastore schema.
5.3.3. The relationship between packages and datastores
As defined by NMDA [RFC8342], each datastore has an associated As defined by NMDA [RFC8342], each datastore has an associated
datastore schema. Sections 5.1 and 5.3 of NMDA defines further datastore schema. Sections 5.1 and 5.3 of NMDA defines further
constraints on the schema associated with datastores. These constraints on the schema associated with datastores. These
constraints can be summarized thus: constraints can be summarized thus:
o The schema for all conventional datastores is the same. * The schema for all conventional datastores is the same.
o The schema for non conventional configuration datastores (e.g., * The schema for non conventional configuration datastores (e.g.,
dynamic datastores) may completely differ (i.e. no overlap at all) dynamic datastores) may completely differ (i.e. no overlap at all)
from the schema associated with the conventional configuration from the schema associated with the conventional configuration
datastores, or may partially or fully overlap with the schema of datastores, or may partially or fully overlap with the schema of
the conventional configuration datastores. A dynamic datastore, the conventional configuration datastores. A dynamic datastore,
for example, may support different modules than conventional for example, may support different modules than conventional
datastores, or may support a subset or superset of modules, datastores, or may support a subset or superset of modules,
features, or data nodes supported in the conventional features, or data nodes supported in the conventional
configuration datastores. Where a data node exists in multiple configuration datastores. Where a data node exists in multiple
datastore schema it has the same type, properties and semantics. datastore schema it has the same type, properties and semantics.
o The schema for the operational datastore is intended to be a * The schema for the operational datastore is intended to be a
superset of all the configuration datastores (i.e. includes all superset of all the configuration datastores (i.e. includes all
the schema nodes from the conventional configuration datastores), the schema nodes from the conventional configuration datastores),
but data nodes can be omitted if they cannot be accurately but data nodes can be omitted if they cannot be accurately
reported. The operational datastore schema can include additional reported. The operational datastore schema can include additional
modules containing only config false data nodes, but there is no modules containing only config false data nodes, but there is no
harm in including those modules in the configuration datastore harm in including those modules in the configuration datastore
schema as well. schema as well.
Given that YANG packages represent a YANG schema, it follows that Given that YANG packages represent a YANG schema, it follows that
each datastore schema can be represented using packages. In each datastore schema can be represented using packages. In
addition, the schema for most datastores on a server are often addition, the schema for most datastores on a server are often
closely related. Given that there are many ways that a datastore closely related. Given that there are many ways that a datastore
schema could be represented using packages, the following guidance schema could be represented using packages, the following guidance
provides a consistent approach to help clients understand the provides a consistent approach to help clients understand the
relationship between the different datastore schema supported by a relationship between the different datastore schema supported by a
device (e.g., which parts of the schema are common and which parts device (e.g., which parts of the schema are common and which parts
have differences): have differences):
o Any datastores (e.g., conventional configuration datastores) that * Any datastores (e.g., conventional configuration datastores) that
have exactly the same datastore schema MUST use the same package have exactly the same datastore schema MUST use the same package
definitions. This is to avoid, for example, the creation of a definitions. This is to avoid, for example, the creation of a
'running-cfg' package and a separate 'intended-cfg' package that 'running-cfg' package and a separate 'intended-cfg' package that
have identical schema. have identical schema.
o Common package definitions SHOULD be used for those parts of the * Common package definitions SHOULD be used for those parts of the
datastore schema that are common between datastores, when those datastore schema that are common between datastores, when those
datastores do not share exactly the same datastore schema. E.g., datastores do not share exactly the same datastore schema. E.g.,
if a substantial part of the schema is common between the if a substantial part of the schema is common between the
conventional, dynamic, and operational datastores then a single conventional, dynamic, and operational datastores then a single
common package can be used to describe the common parts, along common package can be used to describe the common parts, along
with other packages to describe the unique parts of each datastore with other packages to describe the unique parts of each datastore
schema. schema.
o YANG modules that do not contain any configuration data nodes * YANG modules that do not contain any configuration data nodes
SHOULD be included in the package for configuration datastores if SHOULD be included in the package for configuration datastores if
that helps unify the package definitions. that helps unify the package definitions.
o The packages for the operational datastore schema MUST include all * The packages for the operational datastore schema MUST include all
packages for all configuration datastores, along with any required packages for all configuration datastores, along with any required
modules defining deviations to mark unsupported data nodes. The modules defining deviations to mark unsupported data nodes. The
deviations MAY be defined directly in the packages defining the deviations MAY be defined directly in the packages defining the
operational datastore schema, or in separate non referentially operational datastore schema, or in separate non referentially
complete packages. complete packages.
o The schema for a datastore MAY be represented using a single * The schema for a datastore MAY be represented using a single
package or as the union of a set of compatible packages, i.e., package or as the union of a set of compatible packages, i.e.,
equivalently to a set of non-conflicting packages being included equivalently to a set of non-conflicting packages being included
together in an overarching package definition. together in an overarching package definition.
5.4. Schema referential completeness 5.4. Schema referential completeness
A YANG package may represent a schema that is 'referentially A YANG package may represent a schema that is 'referentially
complete', or 'referentially incomplete', indicated in the package complete', or 'referentially incomplete', indicated in the package
definition by the 'complete' flag. definition by the 'complete' flag.
skipping to change at page 17, line 6 skipping to change at page 16, line 21
+-- previous-version? pkg-version +-- previous-version? pkg-version
+-- nbc-changes? boolean +-- nbc-changes? boolean
+-- tag* tags:tag +-- tag* tags:tag
+-- mandatory-feature* scoped-feature +-- mandatory-feature* scoped-feature
+-- included-package* [name version] +-- included-package* [name version]
| +-- name pkg-name | +-- name pkg-name
| +-- version pkg-version | +-- version pkg-version
| +-- replaces-version* pkg-version | +-- replaces-version* pkg-version
| +-- nbc-modified? boolean | +-- nbc-modified? boolean
| +-- location* inet:uri | +-- location* inet:uri
| +-- checksum? pkg-types:sha-256-hash
+-- module* [name] +-- module* [name]
| +-- name yang:yang-identifier | +-- name yang:yang-identifier
| +-- revision? rev:revision-date-or-label | +-- revision? rev:revision-date-or-label
| +-- replaces-revision* rev:revision-date-or-label | +-- replaces-revision* rev:revision-date-or-label
| +-- namespace? inet:uri | +-- namespace? inet:uri
| +-- location* inet:uri | +-- location* inet:uri
| +-- checksum? pkg-types:sha-256-hash
| +-- submodule* [name] | +-- submodule* [name]
| +-- name? yang:yang-identifier | +-- name? yang:yang-identifier
| +-- revision yang:revision-identifier | +-- revision yang:revision-identifier
| +-- location* inet:uri | +-- location* inet:uri
| +-- checksum? pkg-types:sha-256-hash
+-- import-only-module* [name revision] +-- import-only-module* [name revision]
+-- name? yang:yang-identifier +-- name? yang:yang-identifier
+-- revision? rev:revision-date-or-label +-- revision? rev:revision-date-or-label
+-- replaces-revision* rev:revision-date-or-label +-- replaces-revision* rev:revision-date-or-label
+-- namespace? inet:uri +-- namespace? inet:uri
+-- location* inet:uri +-- location* inet:uri
+-- checksum? pkg-types:sha-256-hash
+-- submodule* [name] +-- submodule* [name]
+-- name? yang:yang-identifier +-- name? yang:yang-identifier
+-- revision yang:revision-identifier +-- revision yang:revision-identifier
+-- location* inet:uri +-- location* inet:uri
+-- checksum? pkg-types:sha-256-hash
6. Package Instance Data Files 6. Package Instance Data Files
YANG packages SHOULD be available offline from the server, defined as YANG packages SHOULD be available offline from the server, defined as
YANG instance data files [I-D.ietf-netmod-yang-instance-file-format] YANG instance data files [I-D.ietf-netmod-yang-instance-file-format]
using the YANG schema below to define the package data. using the YANG schema below to define the package data.
The following rules apply to the format of the YANG package instance The following rules apply to the format of the YANG package instance
files: files:
skipping to change at page 18, line 34 skipping to change at page 18, line 4
module: ietf-yang-package module: ietf-yang-package
structure package: structure package:
// Uses the yang-package-instance grouping defined in // Uses the yang-package-instance grouping defined in
// ietf-yang-package-types.yang // ietf-yang-package-types.yang
+-- name pkg-name +-- name pkg-name
+-- version pkg-version +-- version pkg-version
... remainder of yang-package-instance grouping ... ... remainder of yang-package-instance grouping ...
7. Package Definitions on a Server 7. Package Definitions on a Server
7.1. Package List 7.1. Package List
A top level 'packages' container holds the list of all versions of A top level 'packages' container holds the list of all versions of
all packages known to the server. Each list entry uses the common all packages known to the server. Each list entry uses the common
package definition, but with the addition of package location and package definition, but with the addition of package location that
checksum information that cannot be contained within a offline cannot be contained within a offline package definition contained in
package definition contained in an instance data file. an instance data file.
The '/packages/package' list MAY include multiple versions of a The '/packages/package' list MAY include multiple versions of a
particular package. E.g. if the server is capable of allowing particular package. E.g. if the server is capable of allowing
clients to select which package versions should be used by the clients to select which package versions should be used by the
server. server.
7.2. Tree diagram 7.2. Tree diagram
The "ietf-yang-packages" YANG module has the following structure: The "ietf-yang-packages" YANG module has the following structure:
module: ietf-yang-packages module: ietf-yang-packages
+--ro packages +--ro packages
+--ro package* [name version] +--ro package* [name version]
// Uses the yang-package-instance grouping defined in // Uses the yang-package-instance grouping defined in
// ietf-yang-package-types.yang, with location and checksum: // ietf-yang-package-types.yang, with location:
+--ro name pkg-name +--ro name pkg-name
+--ro version pkg-version +--ro version pkg-version
... remainder of yang-package-instance grouping ... ... remainder of yang-package-instance grouping ...
+--ro location* inet:uri +--ro location* inet:uri
+--ro checksum? pkg-types:sha-256-hash
8. YANG Library Package Bindings 8. YANG Library Package Bindings
The YANG packages module also augments YANG library to allow a server The YANG packages module also augments YANG library to allow a server
to optionally indicate that a datastore schema is defined by a to optionally indicate that a datastore schema is defined by a
package, or a union of compatible packages. Since packages can package, or a union of compatible packages. Since packages can
generally be made available offline in instance data files, it may be generally be made available offline in instance data files, it may be
sufficient for a client to only check that a compatible version of sufficient for a client to only check that a compatible version of
the package is implemented by the server without fetching either the the package is implemented by the server without fetching either the
package definition, or downloading and comparing the full list of package definition, or downloading and comparing the full list of
skipping to change at page 20, line 12 skipping to change at page 19, line 18
definition is not supported on a server, but deviations MAY be used definition is not supported on a server, but deviations MAY be used
to disable functionality predicated by an if-feature statement. to disable functionality predicated by an if-feature statement.
The "ietf-yl-packages" YANG module has the following structure: The "ietf-yl-packages" YANG module has the following structure:
module: ietf-yl-packages module: ietf-yl-packages
augment /yanglib:yang-library/yanglib:schema: augment /yanglib:yang-library/yanglib:schema:
+--ro package* [name version] +--ro package* [name version]
+--ro name -> /pkgs:packages/package/name +--ro name -> /pkgs:packages/package/name
+--ro version leafref +--ro version leafref
+--ro checksum? leafref
9. YANG packages as schema for YANG instance data document 9. YANG packages as schema for YANG instance data document
YANG package definitions can be used as the schema definition for YANG package definitions can be used as the schema definition for
YANG instance data files. When using a package schema, the name and YANG instance data files. When using a package schema, the name and
version of the package MUST be specified, a package checksum and/or version of the package MUST be specified, a package URL to the
URL to the package definition MAY also be provided. package definition MAY also be provided.
The "ietf-yang-inst-data-pkg" YANG module has the following The "ietf-yang-inst-data-pkg" YANG module has the following
structure: structure:
module: ietf-yang-inst-data-pkg module: ietf-yang-inst-data-pkg
augment-structure /yid:instance-data-set/yid:content-schema-spec: augment-structure /yid:instance-data-set/yid:content-schema-spec:
+--:(pkg-schema) +--:(pkg-schema)
+-- pkg-schema +-- pkg-schema
+-- name pkg-name +-- name pkg-name
+-- version pkg-version +-- version pkg-version
+-- location* inet:uri +-- location* inet:uri
+-- checksum? pkg-types:sha-256-hash
10. YANG Modules 10. YANG Modules
The YANG module definitions for the modules described in the previous The YANG module definitions for the modules described in the previous
sections. sections.
<CODE BEGINS> file "ietf-yang-package-types@2020-01-21.yang" <CODE BEGINS> file "ietf-yang-package-types@2021-10-25.yang"
module ietf-yang-package-types { module ietf-yang-package-types {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-yang-package-types"; namespace "urn:ietf:params:xml:ns:yang:ietf-yang-package-types";
prefix "pkg-types"; prefix "pkg-types";
import ietf-yang-revisions { import ietf-yang-revisions {
prefix rev; prefix rev;
reference "XXXX: Updated YANG Module Revision Handling"; reference "XXXX: Updated YANG Module Revision Handling";
} }
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
rev:revision-or-derived 2019-07-21; rev:revision-or-derived 2019-07-21;
reference "RFC 6991bis: Common YANG Data Types."; reference "RFC 6991bis: Common YANG Data Types.";
} }
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
skipping to change at page 22, line 15 skipping to change at page 21, line 17
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as 'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here."; they appear in all capitals, as shown here.";
// RFC Ed.: update the date below with the date of RFC publication // RFC Ed.: update the date below with the date of RFC publication
// and remove this note. // and remove this note.
// RFC Ed.: replace XXXX with actual RFC number and remove this // RFC Ed.: replace XXXX with actual RFC number and remove this
// note. // note.
revision 2020-01-21 { revision 2021-10-25 {
rev:revision-label 0.2.0; rev:revision-label 0.2.0;
description description
"Initial revision"; "Initial revision";
reference reference
"RFC XXXX: YANG Packages"; "RFC XXXX: YANG Packages";
} }
/* /*
* Typedefs * Typedefs
*/ */
skipping to change at page 23, line 13 skipping to change at page 22, line 16
} }
description description
"Represents a feature name scoped to a particular module, "Represents a feature name scoped to a particular module,
identified as the '<module-name>:<feature-name>', where both identified as the '<module-name>:<feature-name>', where both
<module-name> and <feature-name> are YANG identifier strings, <module-name> and <feature-name> are YANG identifier strings,
as defiend by Section 12 or RFC 6020."; as defiend by Section 12 or RFC 6020.";
reference reference
"RFC XXXX, YANG Packages."; "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 * Groupings
*/ */
grouping yang-pkg-identification-leafs { grouping yang-pkg-identification-leafs {
description description
"Parameters for identifying a specific version of a YANG "Parameters for identifying a specific version of a YANG
package"; package";
leaf name { leaf name {
type pkg-name; type pkg-name;
skipping to change at page 27, line 38 skipping to change at page 26, line 23
for this YANG package can be found. for this YANG package can be found.
This leaf will only be present if there is a URL available This leaf will only be present if there is a URL available
for retrieval of the schema for this entry. for retrieval of the schema for this entry.
If multiple locations are provided, then the first If multiple locations are provided, then the first
location in the leaf-list MUST be the definitive location location in the leaf-list MUST be the definitive location
that uniquely identifies this package"; that uniquely identifies this package";
} }
leaf checksum {
type pkg-types:sha-256-hash;
description
"The SHA-256 hash calculated on the textual package
definition, represented as a hexadecimal string.";
}
} }
list module { list module {
key "name"; key "name";
description description
"An entry in this list represents a module that must be "An entry in this list represents a module that must be
implemented by a server implementing this package, as per implemented by a server implementing this package, as per
RFC 7950 section 5.6.5, with a particular set of supported RFC 7950 section 5.6.5, with a particular set of supported
features and deviations. features and deviations.
skipping to change at page 29, line 4 skipping to change at page 27, line 32
leaf-list location { leaf-list location {
type inet:uri; type inet:uri;
description description
"Contains a URL that represents the YANG schema resource "Contains a URL that represents the YANG schema resource
for this module. for this module.
This leaf will only be present if there is a URL available This leaf will only be present if there is a URL available
for retrieval of the schema for this entry."; for retrieval of the schema for this entry.";
} }
leaf checksum {
type pkg-types:sha-256-hash;
description
"The SHA-256 hash calculated on the textual module
definition, represented as a hexadecimal string.";
}
list submodule { list submodule {
key "name"; key "name";
description description
"Each entry represents one submodule within the "Each entry represents one submodule within the
parent module."; parent module.";
leaf name { leaf name {
type yang:yang-identifier; type yang:yang-identifier;
description description
skipping to change at page 29, line 42 skipping to change at page 28, line 17
leaf-list location { leaf-list location {
type inet:uri; type inet:uri;
description description
"Contains a URL that represents the YANG schema resource "Contains a URL that represents the YANG schema resource
for this submodule. for this submodule.
This leaf will only be present if there is a URL This leaf will only be present if there is a URL
available for retrieval of the schema for this entry."; available for retrieval of the schema for this entry.";
} }
leaf checksum {
type pkg-types:sha-256-hash;
description
"The SHA-256 hash calculated on the textual submodule
definition, represented as a hexadecimal string.";
}
} }
} }
list import-only-module { list import-only-module {
key "name revision"; key "name revision";
description description
"An entry in this list indicates that the server imports "An entry in this list indicates that the server imports
reusable definitions from the specified revision of the reusable definitions from the specified revision of the
module, but does not implement any protocol accessible module, but does not implement any protocol accessible
objects from this revision. objects from this revision.
skipping to change at page 31, line 4 skipping to change at page 29, line 21
} }
leaf-list location { leaf-list location {
type inet:uri; type inet:uri;
description description
"Contains a URL that represents the YANG schema resource "Contains a URL that represents the YANG schema resource
for this module. for this module.
This leaf will only be present if there is a URL available This leaf will only be present if there is a URL available
for retrieval of the schema for this entry."; for retrieval of the schema for this entry.";
}
leaf checksum {
type pkg-types:sha-256-hash;
description
"The SHA-256 hash calculated on the textual submodule
definition, represented as a hexadecimal string.";
} }
list submodule { list submodule {
key "name"; key "name";
description description
"Each entry represents one submodule within the "Each entry represents one submodule within the
parent module."; parent module.";
leaf name { leaf name {
type yang:yang-identifier; type yang:yang-identifier;
skipping to change at page 31, line 43 skipping to change at page 30, line 4
} }
leaf-list location { leaf-list location {
type inet:uri; type inet:uri;
description description
"Contains a URL that represents the YANG schema resource "Contains a URL that represents the YANG schema resource
for this submodule. for this submodule.
This leaf will only be present if there is a URL This leaf will only be present if there is a URL
available for retrieval of the schema for this entry."; available for retrieval of the schema for this entry.";
}
leaf checksum {
type pkg-types:sha-256-hash;
description
"The SHA-256 hash calculated on the textual submodule
definition, represented as a hexadecimal string.";
} }
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
<CODE BEGINS> file "ietf-yang-package-instance@2020-01-21.yang" <CODE BEGINS> file "ietf-yang-package-instance@2021-10-25.yang"
module ietf-yang-package-instance { module ietf-yang-package-instance {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-yang-package-instance"; namespace "urn:ietf:params:xml:ns:yang:ietf-yang-package-instance";
prefix pkg-inst; prefix pkg-inst;
import ietf-yang-revisions { import ietf-yang-revisions {
prefix rev; prefix rev;
reference "XXXX: Updated YANG Module Revision Handling"; reference "XXXX: Updated YANG Module Revision Handling";
} }
skipping to change at page 33, line 44 skipping to change at page 31, line 45
sx:structure package { sx:structure package {
description description
"Defines the YANG package structure for use in a YANG instance "Defines the YANG package structure for use in a YANG instance
data document."; data document.";
uses pkg-types:yang-pkg-instance; uses pkg-types:yang-pkg-instance;
} }
} }
<CODE ENDS> <CODE ENDS>
<CODE BEGINS> file "ietf-yang-package@2020-01-21.yang" <CODE BEGINS> file "ietf-yang-package@2021-10-25.yang"
module ietf-yang-packages { module ietf-yang-packages {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-yang-packages"; namespace "urn:ietf:params:xml:ns:yang:ietf-yang-packages";
prefix pkgs; prefix pkgs;
import ietf-yang-revisions { import ietf-yang-revisions {
prefix rev; prefix rev;
reference "XXXX: Updated YANG Module Revision Handling"; reference "XXXX: Updated YANG Module Revision Handling";
} }
import ietf-yang-package-types { import ietf-yang-package-types {
skipping to change at page 35, line 9 skipping to change at page 33, line 9
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as 'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here."; they appear in all capitals, as shown here.";
// RFC Ed.: update the date below with the date of RFC publication // RFC Ed.: update the date below with the date of RFC publication
// and remove this note. // and remove this note.
// RFC Ed.: replace XXXX with actual RFC number and remove this // RFC Ed.: replace XXXX with actual RFC number and remove this
// note. // note.
revision 2020-01-21 { revision 2021-10-25 {
rev:revision-label 0.2.0; rev:revision-label 0.2.0;
description description
"Initial revision"; "Initial revision";
reference reference
"RFC XXXX: YANG Packages"; "RFC XXXX: YANG Packages";
} }
/* /*
* Groupings * Groupings
*/ */
skipping to change at page 35, line 44 skipping to change at page 33, line 44
type leafref { type leafref {
path '/pkgs:packages' path '/pkgs:packages'
+ '/pkgs:package[pkgs:name = current()/../name]' + '/pkgs:package[pkgs:name = current()/../name]'
+ '/pkgs:version'; + '/pkgs:version';
} }
description description
"The version of the referenced package."; "The version of the referenced package.";
} }
leaf checksum {
type leafref {
path '/pkgs:packages'
+ '/pkgs:package[pkgs:name = current()/../name]'
+ '[pkgs:version = current()/../version]/pkgs:checksum';
}
description
"The checksum of the referenced package.";
}
} }
grouping yang-ds-pkg-ref { grouping yang-ds-pkg-ref {
description description
"Defines the list used to reference a set of YANG packages that "Defines the list used to reference a set of YANG packages that
collectively represent a datastore schema."; collectively represent a datastore schema.";
list package { list package {
key "name version"; key "name version";
skipping to change at page 37, line 13 skipping to change at page 34, line 50
"Contains a URL that represents where an instance data file "Contains a URL that represents where an instance data file
for this YANG package can be found. for this YANG package can be found.
This leaf will only be present if there is a URL available This leaf will only be present if there is a URL available
for retrieval of the schema for this entry. for retrieval of the schema for this entry.
If multiple locations are provided, then the first If multiple locations are provided, then the first
location in the leaf-list MUST be the definitive location location in the leaf-list MUST be the definitive location
that uniquely identifies this package"; that uniquely identifies this package";
} }
leaf checksum {
type pkg-types:sha-256-hash;
description
"The checksum of the package this schema relates to,
calculated on the 'YANG instance data file' package
definition available in the 'location' leaf list.
This leaf MAY be omitted if the referenced package is
locally scoped without an associated checksum.";
}
} }
} }
} }
<CODE ENDS> <CODE ENDS>
<CODE BEGINS> file "ietf-yl-package@2020-01-21.yang" <CODE BEGINS> file "ietf-yl-package@2020-01-21.yang"
module ietf-yl-packages { module ietf-yl-packages {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-yl-packages"; namespace "urn:ietf:params:xml:ns:yang:ietf-yl-packages";
prefix yl-pkgs; prefix yl-pkgs;
skipping to change at page 39, line 18 skipping to change at page 36, line 42
augment "/yanglib:yang-library/yanglib:schema" { augment "/yanglib:yang-library/yanglib:schema" {
description description
"Allow datastore schema to be related to a set of YANG "Allow datastore schema to be related to a set of YANG
packages"; packages";
uses pkgs:yang-ds-pkg-ref; uses pkgs:yang-ds-pkg-ref;
} }
} }
<CODE ENDS> <CODE ENDS>
<CODE BEGINS> file "ietf-yang-inst-data-pkg@2020-01-21.yang" <CODE BEGINS> file "ietf-yang-inst-data-pkg@2021-10-25.yang"
module ietf-yang-inst-data-pkg { module ietf-yang-inst-data-pkg {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-yang-inst-data-pkg"; namespace "urn:ietf:params:xml:ns:yang:ietf-yang-inst-data-pkg";
prefix yid-pkg; prefix yid-pkg;
import ietf-yang-revisions { import ietf-yang-revisions {
prefix rev; prefix rev;
reference "XXXX: Updated YANG Module Revision Handling"; reference "XXXX: Updated YANG Module Revision Handling";
} }
skipping to change at page 41, line 15 skipping to change at page 38, line 38
sx:augment-structure sx:augment-structure
"/yid:instance-data-set/yid:content-schema-spec" { "/yid:instance-data-set/yid:content-schema-spec" {
description description
"Add package reference to instance data set schema "Add package reference to instance data set schema
specification"; specification";
case pkg-schema { case pkg-schema {
container pkg-schema { container pkg-schema {
uses pkg-types:yang-pkg-identification-leafs; uses pkg-types:yang-pkg-identification-leafs;
leaf checksum {
type pkg-types:sha-256-hash;
description
"The SHA-256 hash of the package, calculated on
the textual package definition, represented as a
hexadecimal string.";
}
leaf-list location { leaf-list location {
type inet:uri; type inet:uri;
description description
"Contains a URL that represents where an instance data "Contains a URL that represents where an instance data
file for this YANG package can be found. file for this YANG package can be found.
This leaf will only be present if there is a URL This leaf will only be present if there is a URL
available for retrieval of the schema for this entry. available for retrieval of the schema for this entry.
If multiple locations are provided, then the first If multiple locations are provided, then the first
skipping to change at page 42, line 21 skipping to change at page 39, line 36
readable data nodes in these YANG modules may be considered sensitive readable data nodes in these YANG modules may be considered sensitive
or vulnerable in some network environments. It is thus important to or vulnerable in some network environments. It is thus important to
control read access (e.g., via get, get-config, or notification) to control read access (e.g., via get, get-config, or notification) to
these data nodes. these data nodes.
One additional key different to YANG library, is that the 'ietf-yang- One additional key different to YANG library, is that the 'ietf-yang-
package' YANG module defines a schema to allow YANG packages to be package' YANG module defines a schema to allow YANG packages to be
defined in YANG instance data files, that are outside the security defined in YANG instance data files, that are outside the security
controls of the network management protocols. Hence, it is important controls of the network management protocols. Hence, it is important
to also consider controlling access to these package instance data to also consider controlling access to these package instance data
files to restrict access to sensitive information. SHA-256 checksums files to restrict access to sensitive information.
are used to ensure the integrity of YANG package definitions,
imported modules, and sub-modules.
As per the YANG library security considerations, the module, revision As per the YANG library security considerations, the module, revision
and version information in YANG packages may help an attacker and version information in YANG packages may help an attacker
identify the server capabilities and server implementations with identify the server capabilities and server implementations with
known bugs since the set of YANG modules supported by a server may known bugs since the set of YANG modules supported by a server may
reveal the kind of device and the manufacturer of the device. Server reveal the kind of device and the manufacturer of the device. Server
vulnerabilities may be specific to particular modules, module vulnerabilities may be specific to particular modules, module
revisions, module features, or even module deviations. For example, revisions, module features, or even module deviations. For example,
if a particular operation on a particular data node is known to cause if a particular operation on a particular data node is known to cause
a server to crash or significantly degrade device performance, then a server to crash or significantly degrade device performance, then
skipping to change at page 44, line 23 skipping to change at page 41, line 37
Feedback helping shape this document has kindly been provided by Andy Feedback helping shape this document has kindly been provided by Andy
Bierman, James Cumming, Mahesh Jethanandani, Balazs Lengyel, Ladislav Bierman, James Cumming, Mahesh Jethanandani, Balazs Lengyel, Ladislav
Lhotka,and Jan Lindblad. Lhotka,and Jan Lindblad.
15. References 15. References
15.1. Normative References 15.1. Normative References
[I-D.ietf-netconf-rfc7895bis] [I-D.ietf-netconf-rfc7895bis]
Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K.,
and R. Wilton, "YANG Library", draft-ietf-netconf- and R. Wilton, "YANG Library", Work in Progress, Internet-
rfc7895bis-07 (work in progress), October 2018. Draft, draft-ietf-netconf-rfc7895bis-07, 17 October 2018,
<https://www.ietf.org/archive/id/draft-ietf-netconf-
rfc7895bis-07.txt>.
[I-D.ietf-netmod-module-tags] [I-D.ietf-netmod-module-tags]
Hopps, C., Berger, L., and D. Bogdanovic, "YANG Module Hopps, C., Berger, L., and D. Bogdanovic, "YANG Module
Tags", draft-ietf-netmod-module-tags-10 (work in Tags", Work in Progress, Internet-Draft, draft-ietf-
progress), February 2020. netmod-module-tags-10, 29 February 2020,
<https://www.ietf.org/archive/id/draft-ietf-netmod-module-
tags-10.txt>.
[I-D.ietf-netmod-yang-data-ext] [I-D.ietf-netmod-yang-data-ext]
Bierman, A., Bjorklund, M., and K. Watsen, "YANG Data Bierman, A., Bjorklund, M., and K. Watsen, "YANG Data
Structure Extensions", draft-ietf-netmod-yang-data-ext-05 Structure Extensions", Work in Progress, Internet-Draft,
(work in progress), December 2019. draft-ietf-netmod-yang-data-ext-05, 9 December 2019,
<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-
data-ext-05.txt>.
[I-D.ietf-netmod-yang-instance-file-format] [I-D.ietf-netmod-yang-instance-file-format]
Lengyel, B. and B. Claise, "YANG Instance Data File Lengyel, B. and B. Claise, "YANG Instance Data File
Format", draft-ietf-netmod-yang-instance-file-format-12 Format", Work in Progress, Internet-Draft, draft-ietf-
(work in progress), April 2020. netmod-yang-instance-file-format-21, 8 October 2021,
<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-
instance-file-format-21.txt>.
[I-D.ietf-netmod-yang-module-versioning] [I-D.ietf-netmod-yang-module-versioning]
Wilton, R., Rahman, R., Lengyel, B., Clarke, J., Sterne, Wilton, R., Rahman, R., Lengyel, B., Clarke, J., and J.
J., Claise, B., and K. D'Souza, "Updated YANG Module Sterne, "Updated YANG Module Revision Handling", Work in
Revision Handling", draft-ietf-netmod-yang-module- Progress, Internet-Draft, draft-ietf-netmod-yang-module-
versioning-01 (work in progress), July 2020. versioning-03, 12 July 2021,
<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-
module-versioning-03.txt>.
[I-D.ietf-netmod-yang-semver] [I-D.ietf-netmod-yang-semver]
Claise, B., Clarke, J., Rahman, R., Wilton, R., Lengyel, Claise, B., Clarke, J., Rahman, R., Wilton, R., Lengyel,
B., Sterne, J., and K. D'Souza, "YANG Semantic B., Sterne, J., and K. D'Souza, "YANG Semantic
Versioning", draft-ietf-netmod-yang-semver-01 (work in Versioning", Work in Progress, Internet-Draft, draft-ietf-
progress), July 2020. netmod-yang-semver-03, 12 July 2021,
<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-
semver-03.txt>.
[I-D.ietf-netmod-yang-solutions] [I-D.ietf-netmod-yang-solutions]
Wilton, R., "YANG Versioning Solution Overview", draft- Wilton, R., "YANG Versioning Solution Overview", Work in
ietf-netmod-yang-solutions-00 (work in progress), March Progress, Internet-Draft, draft-ietf-netmod-yang-
2020. solutions-01, 2 November 2020,
<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-
solutions-01.txt>.
[I-D.ietf-netmod-yang-ver-selection] [I-D.ietf-netmod-yang-ver-selection]
Wilton, R., Rahman, R., Clarke, J., Sterne, J., and W. Bo, Wilton, R., Rahman, R., Clarke, J., Sterne, J., and B. Wu,
"YANG Schema Selection", draft-ietf-netmod-yang-ver- "YANG Schema Selection", Work in Progress, Internet-Draft,
selection-00 (work in progress), March 2020. draft-ietf-netmod-yang-ver-selection-00, 17 March 2020,
<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-
ver-selection-00.txt>.
[I-D.ietf-netmod-yang-versioning-reqs] [I-D.ietf-netmod-yang-versioning-reqs]
Clarke, J., "YANG Module Versioning Requirements", draft- Clarke, J., "YANG Module Versioning Requirements", Work in
ietf-netmod-yang-versioning-reqs-03 (work in progress), Progress, Internet-Draft, draft-ietf-netmod-yang-
June 2020. versioning-reqs-05, 6 July 2021,
<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-
versioning-reqs-05.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
skipping to change at page 46, line 30 skipping to change at page 44, line 18
<https://www.rfc-editor.org/info/rfc8342>. <https://www.rfc-editor.org/info/rfc8342>.
[RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K.,
and R. Wilton, "YANG Library", RFC 8525, and R. Wilton, "YANG Library", RFC 8525,
DOI 10.17487/RFC8525, March 2019, DOI 10.17487/RFC8525, March 2019,
<https://www.rfc-editor.org/info/rfc8525>. <https://www.rfc-editor.org/info/rfc8525>.
15.2. Informative References 15.2. Informative References
[I-D.bierman-netmod-yang-package] [I-D.bierman-netmod-yang-package]
Bierman, A., "The YANG Package Statement", draft-bierman- Bierman, A., "The YANG Package Statement", Work in
netmod-yang-package-00 (work in progress), July 2015. Progress, Internet-Draft, draft-bierman-netmod-yang-
package-00, 6 July 2015, <https://www.ietf.org/archive/id/
draft-bierman-netmod-yang-package-00.txt>.
[I-D.ietf-netmod-artwork-folding] [I-D.ietf-netmod-artwork-folding]
Watsen, K., Auerswald, E., Farrel, A., and Q. WU, Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Inclusions in Internet-Drafts and "Handling Long Lines in Content of Internet-Drafts and
RFCs", draft-ietf-netmod-artwork-folding-12 (work in RFCs", Work in Progress, Internet-Draft, draft-ietf-
progress), January 2020. netmod-artwork-folding-12, 20 January 2020,
<https://www.ietf.org/archive/id/draft-ietf-netmod-
artwork-folding-12.txt>.
[openconfigsemver] [openconfigsemver]
"Semantic Versioning for OpenConfig Models", "Semantic Versioning for OpenConfig Models",
<http://www.openconfig.net/docs/semver/>. <http://www.openconfig.net/docs/semver/>.
[RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module
Classification", RFC 8199, DOI 10.17487/RFC8199, July Classification", RFC 8199, DOI 10.17487/RFC8199, July
2017, <https://www.rfc-editor.org/info/rfc8199>. 2017, <https://www.rfc-editor.org/info/rfc8199>.
Appendix A. Examples Appendix A. Examples
skipping to change at page 47, line 30 skipping to change at page 45, line 24
basic IP configuration. basic IP configuration.
As for all YANG packages, all import dependencies are fully resolved. As for all YANG packages, all import dependencies are fully resolved.
Because this example uses YANG modules that have been standardized Because this example uses YANG modules that have been standardized
before YANG semantic versioning, they modules are referenced by before YANG semantic versioning, they modules are referenced by
revision date rather than version number. revision date rather than version number.
<CODE BEGINS> file "example-ietf-network-device-pkg.json" <CODE BEGINS> file "example-ietf-network-device-pkg.json"
========= NOTE: '\' line wrapping per BCP XX (RFC XXXX) =========== ========= NOTE: '\' line wrapping per BCP XX (RFC XXXX) ===========
{ {
"ietf-yang-instance-data:instance-data-set": { "ietf-yang-instance-data:instance-data-set": {
"name": "example-ietf-network-device-pkg", "name": "example-ietf-network-device-pkg",
"pkg-schema": { "pkg-schema": {
package: "ietf-yang-package-defn-pkg@0.1.0.json" package: "ietf-yang-package-defn-pkg@0.1.0.json"
}, },
"description": "YANG package definition", "description": "YANG package definition",
"content-data": { "content-data": {
"ietf-yang-package-instance:yang-package": { "ietf-yang-package-instance:yang-package": {
"name": "example-ietf-network-device-pkg", "name": "example-ietf-network-device-pkg",
"version": "1.1.2", "version": "1.1.2",
skipping to change at page 48, line 4 skipping to change at page 45, line 45
"timestamp": "2018-12-13T17:00:00Z", "timestamp": "2018-12-13T17:00:00Z",
"organization": "IETF NETMOD Working Group", "organization": "IETF NETMOD Working Group",
"contact" : "WG Web: <http://tools.ietf.org/wg/netmod/>, \ "contact" : "WG Web: <http://tools.ietf.org/wg/netmod/>, \
WG List: <mailto:netmod@ietf.org>", WG List: <mailto:netmod@ietf.org>",
"description": "Example IETF network device YANG package.\ "description": "Example IETF network device YANG package.\
\ \
This package defines a small sample set of \ This package defines a small sample set of \
YANG modules that could represent the basic set of \ YANG modules that could represent the basic set of \
modules that a standard network device might be expected \ modules that a standard network device might be expected \
to support.", to support.",
"reference": "XXX, draft-rwilton-netmod-yang-packages", "reference": "XXX, draft-rwilton-netmod-yang-packages",
"location": [ "file://example.org/yang/packages/\ "location": [ "file://example.org/yang/packages/\
ietf-network-device@v1.1.2.json" ], ietf-network-device@v1.1.2.json" ],
"module": [ "module": [
{ {
"name": "iana-crypt-hash", "name": "iana-crypt-hash",
"revision": "2014-08-06", "revision": "2014-08-06",
"location": [ "https://tiny.cc/ietf-yang/\ "location": [ "https://tiny.cc/ietf-yang/\
iana-crypt-hash%402014-08-06.yang" ], iana-crypt-hash%402014-08-06.yang" ],
"checksum": "fa9fde408ddec2c16bf2c6b9e4c2f80b\
813a2f9e48c127016f3fa96da346e02d"
}, },
{ {
"name": "ietf-system", "name": "ietf-system",
"revision": "2014-08-06", "revision": "2014-08-06",
"location": [ "https://tiny.cc/ietf-yang/\ "location": [ "https://tiny.cc/ietf-yang/\
ietf-system%402014-08-06.yang" ], ietf-system%402014-08-06.yang" ],
"checksum": "8a692ee2521b4ffe87a88303a61a1038\
79ee26bff050c1b05a2027ae23205d3f"
}, },
{ {
"name": "ietf-interfaces", "name": "ietf-interfaces",
"revision": "2018-02-20", "revision": "2018-02-20",
"location": [ "https://tiny.cc/ietf-yang/\ "location": [ "https://tiny.cc/ietf-yang/\
ietf-interfaces%402018-02-20.yang" ], ietf-interfaces%402018-02-20.yang" ],
"checksum": "f6faea9938f0341ed48fda93dba9a69a\
a32ee7142c463342efec3d38f4eb3621"
}, },
{ {
"name": "ietf-netconf-acm", "name": "ietf-netconf-acm",
"revision": "2018-02-14", "revision": "2018-02-14",
"location": [ "https://tiny.cc/ietf-yang/\ "location": [ "https://tiny.cc/ietf-yang/\
ietf-netconf-acm%402018-02-14.yang" ], ietf-netconf-acm%402018-02-14.yang" ],
"checksum": "e03f91317f9538a89296e99df3ff0c40\
03cdfea70bf517407643b3ec13c1ed25"
}, },
{ {
"name": "ietf-key-chain", "name": "ietf-key-chain",
"revision": "2017-06-15", "revision": "2017-06-15",
"location": [ "https://tiny.cc/ietf-yang/\ "location": [ "https://tiny.cc/ietf-yang/\
ietf-key-chain@2017-06-15.yang" ], ietf-key-chain@2017-06-15.yang" ],
"checksum": "6250705f59fc9ad786e8d74172ce90d5\
8deec437982cbca7922af40b3ae8107c"
}, },
{ {
"name": "ietf-ip", "name": "ietf-ip",
"revision": "2018-02-22", "revision": "2018-02-22",
"location": [ "https://tiny.cc/ietf-yang/\ "location": [ "https://tiny.cc/ietf-yang/\
ietf-ip%402018-02-22.yang" ], ietf-ip%402018-02-22.yang" ],
"checksum": "b624c84a66c128ae69ab107a5179ca8e\
20e693fb57dbe5cb56c3db2ebb18c894"
} }
], ],
"import-only-module": [ "import-only-module": [
{ {
"name": "ietf-yang-types", "name": "ietf-yang-types",
"revision": "2013-07-15", "revision": "2013-07-15",
"location": [ "https://tiny.cc/ietf-yang/\ "location": [ "https://tiny.cc/ietf-yang/\
ietf-yang-types%402013-07-15.yang" ], ietf-yang-types%402013-07-15.yang" ],
"checksum": "a04cdcc875764a76e89b7a0200c6b9d8\
00b10713978093acda7840c7c2907c3f"
}, },
{ {
"name": "ietf-inet-types", "name": "ietf-inet-types",
"revision": "2013-07-15", "revision": "2013-07-15",
"location": [ "https://tiny.cc/ietf-yang/\ "location": [ "https://tiny.cc/ietf-yang/\
ietf-inet-types%402013-07-15.yang" ], ietf-inet-types%402013-07-15.yang" ],
"checksum": "12d98b0143a5ca5095b36420f9ebc1ff\
a61cfd2eaa850080244cadf01b86ddf9"
} }
] ]
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
A.2. Example IETF Basic Routing YANG package A.2. Example IETF Basic Routing YANG package
This section provides an instance data file example of a basic IETF This section provides an instance data file example of a basic IETF
Routing YANG package formatted in JSON. Routing YANG package formatted in JSON.
skipping to change at page 50, line 29 skipping to change at page 47, line 52
IETF routing YANG modules that could represent the set of \ IETF routing YANG modules that could represent the set of \
IETF routing functionality that a basic IP network device \ IETF routing functionality that a basic IP network device \
might be expected to support.", might be expected to support.",
"reference": "XXX, draft-rwilton-netmod-yang-packages", "reference": "XXX, draft-rwilton-netmod-yang-packages",
"imported-packages": [ "imported-packages": [
{ {
"name": "ietf-network-device", "name": "ietf-network-device",
"version": "1.1.2", "version": "1.1.2",
"location": [ "http://example.org/yang/packages/\ "location": [ "http://example.org/yang/packages/\
ietf-network-device@v1.1.2.json" ], ietf-network-device@v1.1.2.json" ],
"checksum": ""
} }
], ],
"module": [ "module": [
{ {
"name": "ietf-routing", "name": "ietf-routing",
"revision": "2018-03-13", "revision": "2018-03-13",
"location": [ "https://tiny.cc/ietf-yang/\ "location": [ "https://tiny.cc/ietf-yang/\
ietf-routing@2018-03-13.yang" ], ietf-routing@2018-03-13.yang" ],
"checksum": ""
}, },
{ {
"name": "ietf-ipv4-unicast-routing", "name": "ietf-ipv4-unicast-routing",
"revision": "2018-03-13", "revision": "2018-03-13",
"location": [ "https://tiny.cc/ietf-yang/\ "location": [ "https://tiny.cc/ietf-yang/\
ietf-ipv4-unicast-routing@2018-03-13.yang" ], ietf-ipv4-unicast-routing@2018-03-13.yang" ],
"checksum": ""
}, },
{ {
"name": "ietf-ipv6-unicast-routing", "name": "ietf-ipv6-unicast-routing",
"revision": "2018-03-13", "revision": "2018-03-13",
"location": [ "https://tiny.cc/ietf-yang/\ "location": [ "https://tiny.cc/ietf-yang/\
ietf-ipv6-unicast-routing@2018-03-13.yang" ], ietf-ipv6-unicast-routing@2018-03-13.yang" ],
"checksum": ""
}, },
{ {
"name": "ietf-isis", "name": "ietf-isis",
"revision": "2018-12-11", "revision": "2018-12-11",
"location": [ "https://tiny.cc/ietf-yang/\ "location": [ "https://tiny.cc/ietf-yang/\
" ], " ],
"checksum": ""
}, },
{ {
"name": "ietf-interfaces-common", "name": "ietf-interfaces-common",
"revision": "2018-07-02", "revision": "2018-07-02",
"location": [ "https://tiny.cc/ietf-yang/\ "location": [ "https://tiny.cc/ietf-yang/\
" ], " ],
"checksum": ""
}, },
{ {
"name": "ietf-if-l3-vlan", "name": "ietf-if-l3-vlan",
"revision": "2017-10-30", "revision": "2017-10-30",
"location": [ "https://tiny.cc/ietf-yang/\ "location": [ "https://tiny.cc/ietf-yang/\
" ], " ],
"checksum": ""
}, },
{ {
"name": "ietf-routing-policy", "name": "ietf-routing-policy",
"revision": "2018-10-19", "revision": "2018-10-19",
"location": [ "https://tiny.cc/ietf-yang/\ "location": [ "https://tiny.cc/ietf-yang/\
" ], " ],
"checksum": ""
}, },
{ {
"name": "ietf-bgp", "name": "ietf-bgp",
"revision": "2018-05-09", "revision": "2018-05-09",
"location": [ "https://tiny.cc/ietf-yang/\ "location": [ "https://tiny.cc/ietf-yang/\
" ], " ],
"checksum": ""
}, },
{ {
"name": "ietf-access-control-list", "name": "ietf-access-control-list",
"revision": "2018-11-06", "revision": "2018-11-06",
"location": [ "https://tiny.cc/ietf-yang/\ "location": [ "https://tiny.cc/ietf-yang/\
" ], " ],
"checksum": ""
} }
], ],
"import-only-module": [ "import-only-module": [
{ {
"name": "ietf-routing-types", "name": "ietf-routing-types",
"revision": "2017-12-04", "revision": "2017-12-04",
"location": [ "https://tiny.cc/ietf-yang/\ "location": [ "https://tiny.cc/ietf-yang/\
ietf-routing-types@2017-12-04.yang" ], ietf-routing-types@2017-12-04.yang" ],
"checksum": ""
}, },
{ {
"name": "iana-routing-types", "name": "iana-routing-types",
"revision": "2017-12-04", "revision": "2017-12-04",
"location": [ "https://tiny.cc/ietf-yang/\ "location": [ "https://tiny.cc/ietf-yang/\
iana-routing-types@2017-12-04.yang" ], iana-routing-types@2017-12-04.yang" ],
"checksum": ""
}, },
{ {
"name": "ietf-bgp-types", "name": "ietf-bgp-types",
"revision": "2018-05-09", "revision": "2018-05-09",
"location": [ "https://tiny.cc/ietf-yang/\ "location": [ "https://tiny.cc/ietf-yang/\
" ], " ],
"checksum": ""
}, },
{ {
"name": "ietf-packet-fields", "name": "ietf-packet-fields",
"revision": "2018-11-06", "revision": "2018-11-06",
"location": [ "https://tiny.cc/ietf-yang/\ "location": [ "https://tiny.cc/ietf-yang/\
" ], " ],
"checksum": ""
}, },
{ {
"name": "ietf-ethertypes", "name": "ietf-ethertypes",
"revision": "2018-11-06", "revision": "2018-11-06",
"location": [ "https://tiny.cc/ietf-yang/\ "location": [ "https://tiny.cc/ietf-yang/\
" ], " ],
"checksum": ""
} }
] ]
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
A.3. Package import conflict resolution example A.3. Package import conflict resolution example
skipping to change at page 56, line 19 skipping to change at page 53, line 28
be reused in an instance data file. The use of YANG packages offers be reused in an instance data file. The use of YANG packages offers
several benefits over just using YANG library: several benefits over just using YANG library:
1. Packages allow schema to be built in a hierarchical fashion. 1. Packages allow schema to be built in a hierarchical fashion.
[I-D.ietf-netconf-rfc7895bis] only allows one layer of hierarchy [I-D.ietf-netconf-rfc7895bis] only allows one layer of hierarchy
(using module sets), and there must be no conflicts between (using module sets), and there must be no conflicts between
module revisions in different module-sets. module revisions in different module-sets.
2. Packages can be made available off the box, with a well defined 2. Packages can be made available off the box, with a well defined
unique name, avoiding the need for clients to download, and unique name, avoiding the need for clients to download, and
construct/check the entire YANG schema for each device. Instead construct/check the entire YANG schema for each device. YANG
they can rely on the named packages with secure checksums. YANG
library's use of a 'content-id' is unique only to the device that library's use of a 'content-id' is unique only to the device that
generated them. generated them.
3. Packages may be versioned using a semantic versioning scheme, 3. Packages may be versioned using a semantic versioning scheme,
YANG library does not provide a schema level semantic version YANG library does not provide a schema level semantic version
number. number.
4. For a YANG library instance data file to contain the necessary 4. For a YANG library instance data file to contain the necessary
information, it probably needs both YANG library and various information, it probably needs both YANG library and various
augmentations (e.g. to include each module's semantic version augmentations (e.g. to include each module's semantic version
 End of changes. 116 change blocks. 
280 lines changed or deleted 148 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/