rfc9907v2.txt   rfc9907.txt 
skipping to change at line 149 skipping to change at line 149
4.29. Modeling Abstract Data Structures 4.29. Modeling Abstract Data Structures
4.30. IANA-Maintained YANG Modules 4.30. IANA-Maintained YANG Modules
4.30.1. Context 4.30.1. Context
4.30.2. Guidelines for IANA-Maintained YANG Modules 4.30.2. Guidelines for IANA-Maintained YANG Modules
4.30.3. Guidance for Writing the IANA Considerations for RFCs 4.30.3. Guidance for Writing the IANA Considerations for RFCs
Defining IANA-Maintained YANG Modules Defining IANA-Maintained YANG Modules
5. IANA Considerations 5. IANA Considerations
5.1. YANG Modules 5.1. YANG Modules
5.2. Update in YANG Parameters Registry Group 5.2. Update in YANG Parameters Registry Group
5.3. IANA-Maintained YANG Modules 5.3. IANA-Maintained YANG Modules
6. Operations and Manageability Considerations 5.3.1. Requirements for All Modules
5.3.2. Requirements Subject to Customization
6. Operational Considerations
7. Security Considerations 7. Security Considerations
8. References 8. References
8.1. Normative References 8.1. Normative References
8.2. Informative References 8.2. Informative References
Appendix A. Module Review Checklist Appendix A. Module Review Checklist
Appendix B. Template for IETF Modules Appendix B. Template for IETF Modules
Appendix C. Template for IANA-Maintained YANG Modules Appendix C. Template for IANA-Maintained YANG Modules
Acknowledgments Acknowledgments
Authors' Addresses Authors' Addresses
skipping to change at line 212 skipping to change at line 214
addition to these RFCs. addition to these RFCs.
Section 4.30.3 updates [RFC8126] by providing guidance for writing Section 4.30.3 updates [RFC8126] by providing guidance for writing
the IANA Considerations sections for RFCs that specify IANA- the IANA Considerations sections for RFCs that specify IANA-
maintained YANG modules. maintained YANG modules.
Note that this document is not a YANG tutorial; the reader is Note that this document is not a YANG tutorial; the reader is
expected to know the YANG data modeling language before implementing expected to know the YANG data modeling language before implementing
the guidance in this document. the guidance in this document.
This RFC contains text intended for use as a template as designated
below by the markers "<BEGIN TEMPLATE TEXT>" and "<END TEMPLATE
TEXT>" or other clear designation. Such Template Text is subject to
the provisions of Section 9(b) of the Trust Legal Provisions.
1.1. Changes Since RFC 8407 1.1. Changes Since RFC 8407
The following changes have been made to the guidelines published in The following changes have been made to the guidelines published in
[RFC8407]: [RFC8407]:
* Implemented the following errata reports: [Err5693], [Err5800], * Implemented the following errata reports: [Err5693], [Err5800],
[Err6899], and [Err7416]. [Err6899], and [Err7416].
* Updated the terminology. * Updated the terminology.
* Added a note about notation conventions. * Added a note about notation conventions.
* Updated the reference information of the IETF author guidelines. * Updated the reference information of the IETF author guidelines.
* Updated the guidance so that the "file name" after the <CODE * Updated the guidance so that the "file name" after the "<CODE
BEGINS> tag is mandatory. BEGINS>" tag is mandatory.
* Added code markers for the security template. * Added code markers for the security template.
* Updated the YANG security considerations template to better insist * Updated the YANG security considerations template to better insist
on the key secure transport features. on the key secure transport features.
* Added statements that the security template is not required for * Added statements that the security template is not required for
modules that follow [RFC8791] or define YANG extensions such as modules that follow [RFC8791] or define YANG extensions such as
[RFC7952]. [RFC7952].
skipping to change at line 306 skipping to change at line 313
Section 4.6.4. Section 4.6.4.
* Fixed an inconsistency in Section 4.6.4 that failed to use * Fixed an inconsistency in Section 4.6.4 that failed to use
"derived-from-or-self()" mentioned back in Section 4.6.2. "derived-from-or-self()" mentioned back in Section 4.6.2.
* Added a new section for modeling abstract data structures. * Added a new section for modeling abstract data structures.
* Added a discussion about "must + error-message" constructs for * Added a discussion about "must + error-message" constructs for
state data. state data.
* Added text about summary of changes in revision statements. * Added text about summary of changes in "revision" statements.
* Added a template for IANA-maintained YANG modules. * Added a template for IANA-maintained YANG modules.
* Updated the wiki URLs to use the new structure. * Updated the wiki URLs to use the new structure.
* Added anydata to the list of statements with mandatory * Added anydata to the list of statements with mandatory
description(s) (Section 4.14). description(s) (Section 4.14).
* Fixed an error (invalid statements) in Section 4.24. * Fixed an error (invalid statements) in Section 4.24.
skipping to change at line 539 skipping to change at line 546
revision 2016-03-20 { revision 2016-03-20 {
description "Latest revision"; description "Latest revision";
reference "RFC FFFF: Foo Protocol"; reference "RFC FFFF: Foo Protocol";
} }
// ... more statements // ... more statements
} }
<CODE ENDS> <CODE ENDS>
3.2.1. Example Modules 3.2.1. Example Modules
Example modules are not code components. The <CODE BEGINS> Example modules are not code components. The "<CODE BEGINS>"
convention MUST NOT be used for example modules. However, example convention MUST NOT be used for example modules. However, example
modules MUST be validated (Section 3.10). modules MUST be validated (Section 3.10).
An example module SHOULD be named using the term "example", followed An example module SHOULD be named using the term "example", followed
by a hyphen, followed by a descriptive name, e.g., "example-toaster". by a hyphen, followed by a descriptive name, e.g., "example-toaster".
See Section 4.9 regarding the namespace guidelines for example See Section 4.9 regarding the namespace guidelines for example
modules. modules.
3.3. Terminology Section 3.3. Terminology Section
skipping to change at line 715 skipping to change at line 722
concerns MUST be explicitly listed by name, and the reasons for concerns MUST be explicitly listed by name, and the reasons for
the sensitivity/privacy concerns MUST be explained. the sensitivity/privacy concerns MUST be explained.
Documents that exclusively define modules that follow the extension Documents that exclusively define modules that follow the extension
in [RFC8791] are not required to include the security template in in [RFC8791] are not required to include the security template in
Section 3.7.1. Likewise, following the template is not required for Section 3.7.1. Likewise, following the template is not required for
modules that define YANG extensions such as [RFC7952]. modules that define YANG extensions such as [RFC7952].
3.7.1. Security Considerations Section Template 3.7.1. Security Considerations Section Template
<CODE BEGINS> <BEGIN TEMPLATE TEXT>
X. Security Considerations X. Security Considerations
This section is modeled after the template described in Section 3.7.1 This section is modeled after the template described in Section 3.7.1
of [RFC9907]. of [RFC9907].
The "<module-name>" YANG module defines a data model that is The "<module-name>" YANG module defines a data model that is
designed to be accessed via YANG-based management protocols, designed to be accessed via YANG-based management protocols,
such as Network Configuration Protocol (NETCONF) [RFC6241] such as Network Configuration Protocol (NETCONF) [RFC6241]
and RESTCONF [RFC8040]. These YANG-based management protocols and RESTCONF [RFC8040]. These YANG-based management protocols
(1) have to use a secure transport layer (e.g., Secure Shell (SSH) (1) have to use a secure transport layer (e.g., Secure Shell (SSH)
[RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and (2) have to use [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and (2) have to use
mutual authentication. mutual authentication.
The Network Configuration Access Control Model (NACM) [RFC8341] The Network Configuration Access Control Model (NACM) [RFC8341]
provides the means to restrict access for particular NETCONF or provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content. RESTCONF protocol operations and content.
Note: RFC 8341 (or a future RFC that replaces it) MUST be listed -- Note: RFC 8341 (or a future RFC that replaces it) MUST be listed
as a normative reference. -- as a normative reference.
By default, RFC 4252, RFC 6241, RFC 8040, RFC 8446, RFC 9000, and -- By default, RFC 4252, RFC 6241, RFC 8040, RFC 8446, RFC 9000, and
RFC 9907 (or future RFCs that replace any of them) are listed as -- RFC 9907 (or future RFCs that replace any of them) are listed as
informative references unless normatively cited in other sections -- informative references unless normatively cited in other sections
of the document that specifies the YANG module. -- of the document that specifies the YANG module.
-- Writable nodes section: -- Writable nodes section:
-- --
-- If the data model contains any writable data nodes (those are all -- If the data model contains any writable data nodes (those are all
-- the "config true" nodes), then include the following text: -- the "config true" nodes), then include the following text:
There are a number of data nodes defined in this YANG module that are There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., "config true", which is the writable/creatable/deletable (i.e., "config true", which is the
default). All writable data nodes are likely to be sensitive or default). All writable data nodes are likely to be sensitive or
vulnerable in some network environments. Write vulnerable in some network environments. Write
skipping to change at line 844 skipping to change at line 851
modules. The module by itself does not expose any data nodes that modules. The module by itself does not expose any data nodes that
are writable, data nodes that contain read-only state, or RPCs. are writable, data nodes that contain read-only state, or RPCs.
As such, there are no additional security issues related to As such, there are no additional security issues related to
the YANG module that need to be considered. the YANG module that need to be considered.
Modules that use the groupings that are defined in this document Modules that use the groupings that are defined in this document
should identify the corresponding security considerations. For should identify the corresponding security considerations. For
example, reusing some of these groupings will expose privacy-related example, reusing some of these groupings will expose privacy-related
information (e.g., 'node-example'). information (e.g., 'node-example').
<CODE ENDS> <END TEMPLATE TEXT>
3.8. IANA Considerations Section 3.8. IANA Considerations Section
Each normative YANG module MUST be registered in both the "IETF XML Each normative YANG module MUST be registered in both the "IETF XML
Registry" group [RFC3688] [IANA-XML] and the "YANG Module Names" Registry" group [RFC3688] [IANA-XML] and the "YANG Module Names"
registry [RFC6020] [IANA-MOD-NAMES]. The registration request in the registry [RFC6020] [IANA-MOD-NAMES]. The registration request in the
"YANG Module Names" registry should indicate whether or not the "YANG Module Names" registry should indicate whether or not the
module is IANA-maintained. This applies to new modules and updated module is IANA-maintained. This applies to new modules and updated
modules. An example of an update registration for the "ietf- modules. An example of an update registration for the "ietf-
template" module can be found in Section 5. template" module can be found in Section 5.
skipping to change at line 928 skipping to change at line 935
registry group. registry group.
Name: Name:
Maintained by IANA? Y/N Maintained by IANA? Y/N
Namespace: Namespace:
Prefix: Prefix:
Reference: Reference:
3.9. References Sections 3.9. References Sections
For every import or include statement that appears in a module For every "import" or "include" statement that appears in a module
contained in the specification that identifies a module in a separate contained in the specification that identifies a module in a separate
document, a corresponding normative reference to that document MUST document, a corresponding normative reference to that document MUST
appear in the Normative References section. The reference MUST appear in the Normative References section. The reference MUST
correspond to the specific module version actually used within the correspond to the specific module version actually used within the
specification. specification.
For every normative reference statement that appears in a module For every normative "reference" statement that appears in a module
contained in the specification that identifies a separate document, a contained in the specification that identifies a separate document, a
corresponding normative reference to that document SHOULD appear in corresponding normative reference to that document SHOULD appear in
the Normative References section. The reference SHOULD correspond to the Normative References section. The reference SHOULD correspond to
the specific document version actually used within the specification. the specific document version actually used within the specification.
If the reference statement identifies an informative reference that If the "reference" statement identifies an informative reference that
identifies a separate document, a corresponding informative reference identifies a separate document, a corresponding informative reference
to that document MAY appear in the Informative References section. to that document MAY appear in the Informative References section.
Except the "import" and "revision" statements, note that it is Except the "import" and "revision" statements, note that it is
acceptable to reference RFCs with their labels and without expanding acceptable to reference RFCs with their labels and without expanding
their titles. An example of such use is as follows: their titles. An example of such use is as follows:
leaf site-of-origin { leaf site-of-origin {
type rt-types:route-origin; type rt-types:route-origin;
description description
skipping to change at line 990 skipping to change at line 997
the "--ietf" command-line option MAY be used to identify any IETF the "--ietf" command-line option MAY be used to identify any IETF
guideline issues. guideline issues.
To ensure that a module fits into the line limits of an I-D, the To ensure that a module fits into the line limits of an I-D, the
command "pyang -f yang --keep-comments --yang-line-length 69" should command "pyang -f yang --keep-comments --yang-line-length 69" should
be used. be used.
The "yanglint" program is also freely available from GitHub: The "yanglint" program is also freely available from GitHub:
<https://github.com/CESNET/libyang>. <https://github.com/CESNET/libyang>.
This tool can be used to validate XPath statements within YANG This tool can be used to validate "XPath" statements within YANG
modules. modules.
To check that JSON-encoded examples [RFC7951] comply with the target To check that JSON-encoded examples [RFC7951] comply with the target
data models, programs such as "yangson" or "yanglint" should be used. data models, programs such as "yangson" or "yanglint" should be used.
Both programs are freely available from GitHub: <https://github.com/ Both programs are freely available from GitHub: <https://github.com/
CZ-NIC/yangson> and <https://github.com/CESNET/libyang>. CZ-NIC/yangson> and <https://github.com/CESNET/libyang>.
3.11. Module Extraction Tools 3.11. Module Extraction Tools
A version of 'rfcstrip' that will extract YANG modules from an I-D or A version of 'rfcstrip' that will extract YANG modules from an I-D or
skipping to change at line 1201 skipping to change at line 1208
It is permissible to use common identifiers such as "name" or "id" in It is permissible to use common identifiers such as "name" or "id" in
data definition statements, especially if these data nodes share a data definition statements, especially if these data nodes share a
common data type. common data type.
Identifiers SHOULD NOT carry any special semantics that identify data Identifiers SHOULD NOT carry any special semantics that identify data
modeling properties. Only YANG statements and YANG extension modeling properties. Only YANG statements and YANG extension
statements are designed to convey machine-readable data modeling statements are designed to convey machine-readable data modeling
properties. For example, naming an object "config" or "state" does properties. For example, naming an object "config" or "state" does
not change whether it is configuration data or state data. Only not change whether it is configuration data or state data. Only
defined YANG statements or YANG extension statements can be used to defined YANG statements or YANG "extension" statements can be used to
assign semantics in a machine-readable format in YANG. assign semantics in a machine-readable format in YANG.
4.4. Defaults 4.4. Defaults
In general, it is suggested that substatements containing very common In general, it is suggested that substatements containing very common
default values SHOULD NOT be present. The substatements listed in default values SHOULD NOT be present. The substatements listed in
Table 1 are commonly used with the default value, which would make Table 1 are commonly used with the default value, which would make
the module difficult to read if used everywhere they are allowed. the module difficult to read if used everywhere they are allowed.
+==============+===============+ +==============+===============+
skipping to change at line 1383 skipping to change at line 1390
state data that would hinder the detection by a management system of state data that would hinder the detection by a management system of
abnormal behaviors of a managed entity. abnormal behaviors of a managed entity.
4.6. XPath Usage 4.6. XPath Usage
This section describes guidelines for using the XML Path Language This section describes guidelines for using the XML Path Language
(XPath) [W3C.REC-xpath] within YANG modules. (XPath) [W3C.REC-xpath] within YANG modules.
4.6.1. XPath Evaluation Contexts 4.6.1. XPath Evaluation Contexts
YANG defines five separate contexts for evaluation of XPath YANG defines five separate contexts for evaluation of "XPath"
statements: statements:
1. The "running" datastore: collection of all YANG configuration 1. The "running" datastore: collection of all YANG configuration
data nodes. The document root is the conceptual container (e.g., data nodes. The document root is the conceptual container (e.g.,
"config" in the "edit-config" operation), which is the parent of "config" in the "edit-config" operation), which is the parent of
all top-level data definition statements with a "config" all top-level data definition statements with a "config"
statement value of "true". statement value of "true".
2. State data + the "running" datastore: collection of all YANG data 2. State data + the "running" datastore: collection of all YANG data
nodes. The document root is the conceptual container, parent of nodes. The document root is the conceptual container, parent of
skipping to change at line 1437 skipping to change at line 1444
"description" statement for the grouping. "description" statement for the grouping.
4.6.2. Function Library 4.6.2. Function Library
The "position" and "last" functions SHOULD NOT be used. This applies The "position" and "last" functions SHOULD NOT be used. This applies
to implicit use of the "position" function as well (e.g., to implicit use of the "position" function as well (e.g.,
'//chapter[42]'). A server is only required to maintain the relative '//chapter[42]'). A server is only required to maintain the relative
XML document order of all instances of a particular user-ordered list XML document order of all instances of a particular user-ordered list
or leaf-list. The "position" and "last" functions MAY be used if or leaf-list. The "position" and "last" functions MAY be used if
they are evaluated in a context where the context node is a user- they are evaluated in a context where the context node is a user-
ordered "list" or "leaf-list". ordered list or leaf-list.
The "id" function SHOULD NOT be used. The "ID" attribute is not The "id" function SHOULD NOT be used. The "ID" attribute is not
present in YANG documents, so this function has no meaning. The present in YANG documents, so this function has no meaning. The
XPath execution environment SHOULD return an empty string for this XPath execution environment SHOULD return an empty string for this
function. function.
The "namespace-uri" and "name" functions SHOULD NOT be used. The "namespace-uri" and "name" functions SHOULD NOT be used.
Expanded names in XPath are different than YANG. A specific Expanded names in XPath are different than YANG. A specific
canonical representation of a YANG-expanded name does not exist. canonical representation of a YANG-expanded name does not exist.
skipping to change at line 1461 skipping to change at line 1468
function. function.
The "local-name", "namespace-uri", "name", "string", and "number" The "local-name", "namespace-uri", "name", "string", and "number"
functions SHOULD NOT be used if the argument is a node-set. If so, functions SHOULD NOT be used if the argument is a node-set. If so,
the function result will be determined by the document order of the the function result will be determined by the document order of the
node-set. Since this order can be different on each server, the node-set. Since this order can be different on each server, the
function results can also be different. Any function call that function results can also be different. Any function call that
implicitly converts a node-set to a string will also have this issue. implicitly converts a node-set to a string will also have this issue.
The "local-name" function SHOULD NOT be used to reference local names The "local-name" function SHOULD NOT be used to reference local names
outside of the YANG module that defines the must or when expression outside of the YANG module that defines the "must" or "when"
containing the "local-name" function. Example of a "local-name" statement containing the "local-name" function. Example of a "local-
function that should not be used: name" function that should not be used:
/*[local-name()='foo'] /*[local-name()='foo']
The "derived-from-or-self" function SHOULD be used instead of an The "derived-from-or-self" function SHOULD be used instead of an
equality expression for identityref values. This allows the equality expression for identityref values. This allows the
identities to be conceptually augmented. identities to be conceptually augmented.
Example: Example:
// assume "ex" is the prefix of the module where the identity // assume "ex" is the prefix of the module where the identity
skipping to change at line 1558 skipping to change at line 1565
} }
4.6.5. Wildcards 4.6.5. Wildcards
It is possible to construct XPath expressions that will evaluate It is possible to construct XPath expressions that will evaluate
differently when combined with several modules within a server differently when combined with several modules within a server
implementation rather than when evaluated within the single module. implementation rather than when evaluated within the single module.
This is due to augmenting nodes from other modules. This is due to augmenting nodes from other modules.
Wildcard expansion is done within a server against all the nodes from Wildcard expansion is done within a server against all the nodes from
all namespaces, so it is possible for a "must" or "when" expression all namespaces, so it is possible for a "must" or "when" statement
that uses the '*' operator to always evaluate to false if processed that uses the '*' operator to always evaluate to false if processed
within a single YANG module. In such cases, the "description" within a single YANG module. In such cases, the "description"
statement SHOULD clarify that augmenting objects are expected to statement SHOULD clarify that augmenting objects are expected to
match the wildcard expansion. match the wildcard expansion.
when /foo/services/*/active { when /foo/services/*/active {
description description
"No services directly defined in this module. "No services directly defined in this module.
Matches objects that have augmented the services container."; Matches objects that have augmented the services container.";
} }
skipping to change at line 1629 skipping to change at line 1636
changed from "current" directly to "obsolete". An object SHOULD be changed from "current" directly to "obsolete". An object SHOULD be
available for at least one year after the publication date with a available for at least one year after the publication date with a
"deprecated" status before it is changed to "obsolete". "deprecated" status before it is changed to "obsolete".
The module or submodule name MUST NOT be changed once the document The module or submodule name MUST NOT be changed once the document
containing the module or submodule is published. containing the module or submodule is published.
The module namespace URI value MUST NOT be changed once the document The module namespace URI value MUST NOT be changed once the document
containing the module is published. containing the module is published.
The revision date substatement within the import statement SHOULD be The revision date substatement within the "import" statement SHOULD
present if any groupings are used from the external module. be present if any groupings are used from the external module.
The revision date substatement within the include statement SHOULD be The revision date substatement within the "include" statement SHOULD
present if any groupings are used from the external submodule. be present if any groupings are used from the external submodule.
If an import statement is for a module from a stable source (e.g., an If an "import" statement is for a module from a stable source (e.g.,
RFC for an IETF module), then a reference-stmt SHOULD be present an RFC for an IETF module), then a reference-stmt SHOULD be present
within an import statement. within an "import" statement.
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
reference "RFC 9911: Common YANG Data Types"; reference "RFC 9911: Common YANG Data Types";
} }
If submodules are used, then the document containing the main module If submodules are used, then the document containing the main module
MUST be updated so that the main module revision date is equal to or MUST be updated so that the main module revision date is equal to or
more recent than the revision date of any submodule that is (directly more recent than the revision date of any submodule that is (directly
or indirectly) included by the main module. or indirectly) included by the main module.
skipping to change at line 1691 skipping to change at line 1698
The "description" statement MUST be present. For modules published The "description" statement MUST be present. For modules published
within IETF documents, the appropriate IETF Trust Copyright text MUST within IETF documents, the appropriate IETF Trust Copyright text MUST
be present, as described in Section 3.1, and MUST contain the be present, as described in Section 3.1, and MUST contain the
following statement: following statement:
| All revisions of IETF and IANA published modules can be found at | All revisions of IETF and IANA published modules can be found at
| the "YANG Parameters" registry group: | the "YANG Parameters" registry group:
| <https://www.iana.org/assignments/yang-parameters>. | <https://www.iana.org/assignments/yang-parameters>.
If the module relies on information contained in other documents, If the module relies on information contained in other documents,
which are not the same documents implied by the import statements which are not the same documents implied by the "import" statements
present in the module, then these documents MUST be identified in the present in the module, then these documents MUST be identified in the
reference statement. "reference" statement.
A "revision" statement MUST be present for each published version of A "revision" statement MUST be present for each published version of
the module. The "revision" statement MUST have a "reference" the module. The "revision" statement MUST have a "reference"
substatement. It MUST identify the published document that contains substatement. It MUST identify the published document that contains
the module. Modules are often extracted from their original the module. Modules are often extracted from their original
documents, and it is useful for developers and operators to know how documents, and it is useful for developers and operators to know how
to find the original source document in a consistent manner. The to find the original source document in a consistent manner. The
"revision" statement MAY have a "description" substatement. For "revision" statement MAY have a "description" substatement. For
convenience, the description text of a new published revision may convenience, the description text of a new published revision may
summarize any changes made to a module compared to the previous summarize any changes made to a module compared to the previous
published revision. Typically, that list is a YANG-specific subset published revision. Typically, that list is a YANG-specific subset
of the summary of changes listing any changes made from the RFC being of the summary of changes listing any changes made from the RFC being
updated or obsoleted as per [ID-Guidelines]. updated or obsoleted as per [ID-Guidelines].
The following example shows the revision statement for a published The following example shows the "revision" statement for a published
YANG module: YANG module:
revision 2010-09-24 { revision 2010-09-24 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC 6021: Common YANG Data Types"; "RFC 6021: Common YANG Data Types";
} }
The following example shows the revision statements for a published The following example shows the "revision" statements for a published
YANG module that updates a published module. The new revision YANG module that updates a published module. The new "revision"
statement summarizes the changes compared to the previous published statement summarizes the changes compared to the previous published
revision. revision.
revision 2013-07-15 { revision 2013-07-15 {
description description
"This revision adds the following new data types: "This revision adds the following new data types:
- yang:yang-identifier - yang:yang-identifier
- yang:hex-string - yang:hex-string
- yang:uuid - yang:uuid
- yang:dotted-quad"; - yang:dotted-quad";
reference reference
"RFC 9911: Common YANG Data Types"; "RFC 6991: Common YANG Data Types";
} }
revision 2010-09-24 { revision 2010-09-24 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC 6021: Common YANG Data Types"; "RFC 6021: Common YANG Data Types";
} }
For an unpublished module, a complete history of each unpublished For an unpublished module, a complete history of each unpublished
module revision is not required. That is, within a sequence of draft module revision is not required. That is, within a sequence of draft
versions, only the most recent revision need be recorded in the versions, only the most recent revision need be recorded in the
module. Do not remove or reuse a revision statement for a published module. Do not remove or reuse a "revision" statement for a
module. A new revision date is not required unless the module published module. A new revision date is not required unless the
contents have changed. If the module contents have changed, then the module contents have changed. If the module contents have changed,
revision date of that new module version MUST be updated to a date then the revision date of that new module version MUST be updated to
later than that of the previous version. a date later than that of the previous version.
The following example shows the revision statements for an The following example shows the "revision" statements for an
unpublished update to a published YANG module. The latest revision unpublished update to a published YANG module. The latest "revision"
statement of the unpublished module summarizes the changes compared statement of the unpublished module summarizes the changes compared
to the previous revision. to the previous revision.
revision 2025-12-22 { revision 2025-12-22 {
description description
"This revision adds the following new data types: "This revision adds the following new data types:
- yang:date - yang:date
- yang:date-no-zone - yang:date-no-zone
- yang:time - yang:time
- yang:time-no-zone - yang:time-no-zone
skipping to change at line 1789 skipping to change at line 1796
} }
revision 2013-07-15 { revision 2013-07-15 {
description description
"This revision adds the following new data types: "This revision adds the following new data types:
- yang:yang-identifier - yang:yang-identifier
- yang:hex-string - yang:hex-string
- yang:uuid - yang:uuid
- yang:dotted-quad"; - yang:dotted-quad";
reference reference
"RFC 9911: Common YANG Data Types"; "RFC 6991: Common YANG Data Types";
} }
revision 2010-09-24 { revision 2010-09-24 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC 6021: Common YANG Data Types"; "RFC 6021: Common YANG Data Types";
} }
4.9. Namespace Assignments 4.9. Namespace Assignments
skipping to change at line 1908 skipping to change at line 1915
type for the particular application. type for the particular application.
The signed numeric data types (i.e., "int8", "int16", "int32", and The signed numeric data types (i.e., "int8", "int16", "int32", and
"int64") SHOULD NOT be used unless negative values are allowed for "int64") SHOULD NOT be used unless negative values are allowed for
the desired semantics. the desired semantics.
4.11.1. Fixed-Value Extensibility 4.11.1. Fixed-Value Extensibility
If the set of values is fixed and the data type contents are If the set of values is fixed and the data type contents are
controlled by a single naming authority (e.g., IANA), then an controlled by a single naming authority (e.g., IANA), then an
enumeration data type SHOULD be used. "enumeration" data type SHOULD be used.
leaf foo { leaf foo {
type enumeration { type enumeration {
enum one; enum one;
enum two; enum two;
} }
} }
If distributed extensibility or hierarchical organization of If distributed extensibility or hierarchical organization of
enumerated values is required, then the "identityref" data type enumerated values is required, then the "identityref" data type
SHOULD be used instead of an enumeration or other built-in type. SHOULD be used instead of an "enumeration" or other built-in type.
identity foo-type { identity foo-type {
description "Base for the extensible type"; description "Base for the extensible type";
} }
identity one { identity one {
base f:foo-type; base f:foo-type;
} }
identity two { identity two {
skipping to change at line 1964 skipping to change at line 1971
the "pattern" statement: the "pattern" statement:
typedef ipv6-address-no-zone { typedef ipv6-address-no-zone {
type inet:ipv6-address { type inet:ipv6-address {
pattern '[0-9a-fA-F:\.]*'; pattern '[0-9a-fA-F:\.]*';
} }
... ...
} }
For string data types, if the length of the string is required to be For string data types, if the length of the string is required to be
bounded in all implementations, then a length statement MUST be bounded in all implementations, then a "length" statement MUST be
present. present.
The following typedef from [RFC9911] demonstrates the proper use of The following typedef from [RFC9911] demonstrates the proper use of
the "length" statement: the "length" statement:
typedef yang-identifier { typedef yang-identifier {
type string { type string {
length "1..max"; length "1..max";
pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*'; pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*';
pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*'; pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*';
skipping to change at line 2143 skipping to change at line 2150
semantics, then a default statement SHOULD be present. semantics, then a default statement SHOULD be present.
If a significant number of derived types are defined, and it is If a significant number of derived types are defined, and it is
anticipated that these data types will be reused by multiple modules, anticipated that these data types will be reused by multiple modules,
then these derived types SHOULD be contained in a separate module or then these derived types SHOULD be contained in a separate module or
submodule to allow easier reuse without unnecessary coupling. submodule to allow easier reuse without unnecessary coupling.
The "description" statement MUST be present. The "description" statement MUST be present.
If the type definition semantics are defined in an external document If the type definition semantics are defined in an external document
(other than another YANG module indicated by an import statement), (other than another YANG module indicated by an "import" statement),
then the reference statement MUST be present. then the "reference" statement MUST be present.
4.13. Reusable Groupings 4.13. Reusable Groupings
A reusable grouping is a YANG grouping that can be imported by A reusable grouping is a YANG grouping that can be imported by
another module and is intended for use by other modules. This is not another module and is intended for use by other modules. This is not
the same as a grouping that is used within the module in which it is the same as a grouping that is used within the module in which it is
defined, but it happens to be exportable to another module because it defined, but it happens to be exportable to another module because it
is defined at the top level of the YANG module. is defined at the top level of the YANG module.
The following guidelines apply to reusable groupings, in order to The following guidelines apply to reusable groupings, in order to
skipping to change at line 2214 skipping to change at line 2221
* list * list
* notification * notification
* rpc * rpc
* typedef * typedef
If the data definition semantics are defined in an external document, If the data definition semantics are defined in an external document,
(other than another YANG module indicated by an import statement), (other than another YANG module indicated by an "import" statement),
then a reference statement MUST be present. then a "reference" statement MUST be present.
The "anyxml" construct may be useful to represent an HTML banner The "anyxml" construct may be useful to represent an HTML banner
containing markup elements, such as "<b>" and "</b>", and MAY be used containing markup elements, such as "<b>" and "</b>", and MAY be used
in such cases. However, this construct SHOULD NOT be used if other in such cases. However, this construct SHOULD NOT be used if other
YANG data node types can be used instead to represent the desired YANG data node types can be used instead to represent the desired
syntax and semantics. syntax and semantics.
It has been found that the "anyxml" statement is not implemented It has been found that the "anyxml" statement is not implemented
consistently across all servers. It is possible that mixed-mode XML consistently across all servers. It is possible that mixed-mode XML
will not be supported or that configuration anyxml nodes will not be will not be supported or that configuration anyxml nodes will not be
skipping to change at line 2306 skipping to change at line 2313
are loaded are loaded
* for subtree filtering, retrieval of a top-level leaf-list will be * for subtree filtering, retrieval of a top-level leaf-list will be
treated as a content-match node for all top-level-siblings treated as a content-match node for all top-level-siblings
* a top-level list with many instances may impact performance * a top-level list with many instances may impact performance
4.15. Operation Definitions 4.15. Operation Definitions
If the operation semantics are defined in an external document (other If the operation semantics are defined in an external document (other
than another YANG module indicated by an import statement), then a than another YANG module indicated by an "import" statement), then a
reference statement MUST be present. "reference" statement MUST be present.
If the operation impacts system behavior in some way, it SHOULD be If the operation impacts system behavior in some way, it SHOULD be
mentioned in the "description" statement. mentioned in the "description" statement.
If the operation is potentially harmful to system behavior in some If the operation is potentially harmful to system behavior in some
way, it MUST be mentioned in the Security Considerations section of way, it MUST be mentioned in the Security Considerations section of
the document. the document.
4.16. Notification Definitions 4.16. Notification Definitions
The "description" statement MUST be present. The "description" statement MUST be present.
If the notification semantics are defined in an external document If the notification semantics are defined in an external document
(other than another YANG module indicated by an import statement), (other than another YANG module indicated by an "import" statement),
then a reference statement MUST be present. then a "reference" statement MUST be present.
If the notification refers to a specific resource instance, then this If the notification refers to a specific resource instance, then this
instance SHOULD be identified in the notification data. This is instance SHOULD be identified in the notification data. This is
usually done by including "leafref" leaf nodes with the key leaf usually done by including "leafref" leaf nodes with the key leaf
values for the resource instance. For example: values for the resource instance. For example:
notification interface-up { notification interface-up {
description "Sent when an interface is activated."; description "Sent when an interface is activated.";
leaf name { leaf name {
type leafref { type leafref {
skipping to change at line 2400 skipping to change at line 2407
4.18. YANG Data Node Constraints 4.18. YANG Data Node Constraints
4.18.1. Controlling Quantity 4.18.1. Controlling Quantity
The "min-elements" and "max-elements" statements can be used to The "min-elements" and "max-elements" statements can be used to
control how many list or leaf-list instances are required for a control how many list or leaf-list instances are required for a
particular data node. YANG constraint statements SHOULD be used to particular data node. YANG constraint statements SHOULD be used to
identify conditions that apply to all implementations of the data identify conditions that apply to all implementations of the data
model. If platform-specific limitations (e.g., the "max-elements" model. If platform-specific limitations (e.g., the "max-elements"
supported for a particular list) are relevant to operations, then a supported for a particular list) are relevant to operations, then a
data model definition statement (e.g., "max-ports" leaf) SHOULD be data model "definition" statement (e.g., "max-ports" leaf) SHOULD be
used to identify the limit. used to identify the limit.
4.18.2. "must" versus "when" 4.18.2. "must" versus "when"
"must" and "when" YANG statements are used to provide cross-object "must" and "when" YANG statements are used to provide cross-object
referential tests. They have very different behavior. The "when" referential tests. They have very different behavior. The "when"
statement causes data node instances to be silently deleted as soon statement causes data node instances to be silently deleted as soon
as the condition becomes false. A false "when" expression is not as the condition becomes false. A false "when" statement is not
considered to be an error. considered to be an error.
The "when" statement SHOULD be used together with "augment" or "uses" The "when" statement SHOULD be used together with "augment" or "uses"
statements to achieve conditional model composition. The condition statements to achieve conditional model composition. The condition
SHOULD be based on static properties of the augmented entry (e.g., SHOULD be based on static properties of the augmented entry (e.g.,
list key leafs). list key leafs).
The "must" statement causes a datastore validation error if the The "must" statement causes a datastore validation error if the
condition is false. This statement SHOULD be used for enforcing condition is false. This statement SHOULD be used for enforcing
parameter value restrictions that involve more than one data node parameter value restrictions that involve more than one data node
(e.g., end-time parameter must be after the start-time parameter). (e.g., end-time parameter must be after the start-time parameter).
4.19. "augment" Statements 4.19. "augment" Statements
The YANG "augment" statement is used to define a set of data The YANG "augment" statement is used to define a set of data
definition statements that will be added as child nodes of a target "definition" statements that will be added as child nodes of a target
data node. The module namespace for these data nodes will be the data node. The module namespace for these data nodes will be the
augmenting module, not the augmented module. augmenting module, not the augmented module.
A top-level "augment" statement SHOULD NOT be used if the target data A top-level "augment" statement SHOULD NOT be used if the target data
node is in the same module or submodule as the evaluated "augment" node is in the same module or submodule as the evaluated "augment"
statement. The data definition statements SHOULD be added inline statement. The data "definition" statements SHOULD be added inline
instead. instead.
4.19.1. Conditional Augment Statements 4.19.1. Conditional Augment Statements
The "augment" statement is often used together with the "when" The "augment" statement is often used together with the "when"
statement and/or "if-feature" statement to make the augmentation statement and/or "if-feature" statement to make the augmentation
conditional on some portion of the data model. conditional on some portion of the data model.
The following example from [RFC8343] shows how a conditional The following example from [RFC8343] shows how a conditional
container called "ethernet" is added to the "interface" list only for container called "ethernet" is added to the "interface" list only for
skipping to change at line 2514 skipping to change at line 2521
} }
} }
} }
Note that this practice is safe only for creating data resources. It Note that this practice is safe only for creating data resources. It
is not safe for replacing or modifying resources if the client does is not safe for replacing or modifying resources if the client does
not know about the new condition. The YANG data model MUST be not know about the new condition. The YANG data model MUST be
packaged in a way that requires the client to be aware of the packaged in a way that requires the client to be aware of the
mandatory data nodes if it is aware of the condition for this data. mandatory data nodes if it is aware of the condition for this data.
In the example above, the "some-new-iftype" identity is defined in In the example above, the "some-new-iftype" identity is defined in
the same module as the "mandatory-leaf" data definition statement. the same module as the "mandatory-leaf" data "definition" statement.
This practice is not safe for identities defined in a common module This practice is not safe for identities defined in a common module
such as "iana-if-type" because the client is not required to know such as "iana-if-type" because the client is not required to know
about "my-module" just because it knows about the "iana-if-type" about "my-module" just because it knows about the "iana-if-type"
module. module.
4.20. Deviation Statements 4.20. Deviation Statements
Per Section 7.20.3 of [RFC7950], the YANG "deviation" statement is Per Section 7.20.3 of [RFC7950], the YANG "deviation" statement is
not allowed to appear in IETF YANG modules, but it can be useful for not allowed to appear in IETF YANG modules, but it can be useful for
skipping to change at line 2571 skipping to change at line 2578
deviation /bk:backups/bk:backup { deviation /bk:backups/bk:backup {
deviate add { deviate add {
max-elements 10; max-elements 10;
} }
} }
4.21. Extension Statements 4.21. Extension Statements
The YANG "extension" statement is used to specify external The YANG "extension" statement is used to specify external
definitions. This appears in the YANG syntax as an "unknown- definitions. This appears in the YANG syntax as an "unknown-
statement". Usage of extension statements in a published module statement". Usage of "extension" statements in a published module
needs to be considered carefully. needs to be considered carefully.
The following guidelines apply to the usage of YANG extensions: The following guidelines apply to the usage of YANG extensions:
* The semantics of the extension MUST NOT contradict any YANG * The semantics of the extension MUST NOT contradict any YANG
statements. Extensions can add semantics not covered by the statements. Extensions can add semantics not covered by the
normal YANG statements. normal YANG statements.
* The module containing the extension statement MUST clearly * The module containing the "extension" statement MUST clearly
identify the conformance requirements for the extension. It identify the conformance requirements for the extension. It
should be clear whether all implementations of the YANG module should be clear whether all implementations of the YANG module
containing the extension need to also implement the extension. If containing the extension need to also implement the extension. If
not, identify what conditions apply that would require not, identify what conditions apply that would require
implementation of the extension. implementation of the extension.
* The extension MUST clearly identify where it can be used within * The extension MUST clearly identify where it can be used within
other YANG statements. other YANG statements.
* The extension MUST clearly identify if YANG statements or other * The extension MUST clearly identify if YANG statements or other
skipping to change at line 2757 skipping to change at line 2764
used on servers supporting the operational state datastore. With used on servers supporting the operational state datastore. With
this in mind, YANG modules SHOULD define "config false" nodes this in mind, YANG modules SHOULD define "config false" nodes
wherever they make sense to the data model. "Config false" nodes wherever they make sense to the data model. "Config false" nodes
SHOULD NOT be defined to provide the operational value for SHOULD NOT be defined to provide the operational value for
configuration nodes, except when the value space of a configured and configuration nodes, except when the value space of a configured and
operational value may differ, in which case a distinct "config false" operational value may differ, in which case a distinct "config false"
node SHOULD be defined to hold the operational value for the node SHOULD be defined to hold the operational value for the
configured node. configured node.
The following guidelines are meant to help modelers develop YANG The following guidelines are meant to help modelers develop YANG
modules that will maximize the utility of the model with both current modules that will maximize the utility of the module with both
and new implementations. current and new implementations.
New modules and modules that are not concerned with the operational New modules and modules that are not concerned with the operational
state of configuration information SHOULD immediately be structured state of configuration information SHOULD immediately be structured
to be NMDA compatible, as described in Section 4.23.1. This to be NMDA compatible, as described in Section 4.23.1. This
transition MAY be deferred if the module does not contain any transition MAY be deferred if the module does not contain any
configuration datastore objects. configuration datastore objects.
The remaining are options that MAY be followed during the time that The remaining are options that MAY be followed during the time that
NMDA mechanisms are being defined. NMDA mechanisms are being defined.
(a) Modules that require immediate support for the NMDA features (a) Modules that require immediate support for the NMDA features
SHOULD be structured for NMDA. A temporary non-NMDA version of SHOULD be structured for NMDA. A temporary non-NMDA version of
this type of module MAY exist, as either an existing model or a this type of module MAY exist, as either an existing module or a
model created by hand or with suitable tools that mirror the module created by hand or with suitable tools that mirror the
current modeling strategies. Both the NMDA and the non-NMDA current modeling strategies. Both the NMDA and the non-NMDA
modules SHOULD be published in the same document, with NMDA modules SHOULD be published in the same document, with NMDA
modules in the document main body and the non-NMDA modules in a modules in the document main body and the non-NMDA modules in a
non-normative appendix. The use of the non-NMDA module will non-normative appendix. The use of the non-NMDA module will
allow temporary bridging of the time period until NMDA allow temporary bridging of the time period until NMDA
implementations are available. implementations are available.
(b) For published models, the model should be republished with an (b) For published modules, the module should be republished with an
NMDA-compatible structure, deprecating non-NMDA constructs. For NMDA-compatible structure, deprecating non-NMDA constructs. For
example, the "ietf-interfaces" model in [RFC7223] has been example, the "ietf-interfaces" module in [RFC7223] has been
restructured as an NMDA-compatible model in [RFC8343] (which restructured as an NMDA-compatible module in [RFC8343] (which
obsoletes [RFC7223]). The "/interfaces-state" hierarchy has obsoletes [RFC7223]). The "/interfaces-state" hierarchy has
been marked "status deprecated". Models that mark their "/foo- been marked with "status deprecated". Modules that mark their
state" hierarchy with "status deprecated" will allow NMDA- "/foo-state" hierarchy with "status deprecated" will allow NMDA-
capable implementations to avoid the cost of duplicating the capable implementations to avoid the cost of duplicating the
state nodes, while enabling non-NMDA-capable implementations to state nodes, while enabling non-NMDA-capable implementations to
utilize them for access to the operational values. utilize them for access to the operational values.
(c) For models that augment models that have not been structured (c) For modules that augment modules that have not been structured
with the NMDA, the modeler will have to consider the structure with the NMDA, the modeler will have to consider the structure
of the base model and the guidelines listed above. Where of the base module and the guidelines listed above. Where
possible, such models should move to new revisions of the base possible, such modules should move to new revisions of the base
model that are NMDA compatible. When that is not possible, module that are NMDA compatible. When that is not possible,
augmenting "state" containers SHOULD be avoided, with the augmenting "state" containers SHOULD be avoided, with the
expectation that the base model will be re-released with the expectation that the base module will be re-released with the
state containers marked as deprecated. It is RECOMMENDED to state containers marked as "deprecated". It is RECOMMENDED to
augment only the "/foo" hierarchy of the base model. Where this augment only the "/foo" hierarchy of the base module. Where
recommendation cannot be followed, any new "state" elements this recommendation cannot be followed, any new "state" elements
SHOULD be included in their own module. SHOULD be included in their own module.
4.23.3.1. Temporary Non-NMDA Modules 4.23.3.1. Temporary Non-NMDA Modules
A temporary non-NMDA module allows a non-NMDA-aware client to access A temporary non-NMDA module allows a non-NMDA-aware client to access
operational state from an NMDA-compliant server. It contains the operational state from an NMDA-compliant server. It contains the
top-level "config false" data nodes that would have been defined in a top-level "config false" data nodes that would have been defined in a
legacy YANG module (before NMDA). legacy YANG module (before NMDA).
A server that needs to support both NMDA and non-NMDA clients can A server that needs to support both NMDA and non-NMDA clients can
advertise both the new NMDA module and the temporary non-NMDA module. advertise both the new NMDA module and the temporary non-NMDA module.
A non-NMDA client can use separate "foo" and "foo-state" subtrees, A non-NMDA client can use separate "foo" and "foo-state" subtrees,
except the "foo-state" subtree is located in a different (temporary) except the "foo-state" subtree is located in a different (temporary)
module. The NMDA module can be used by a non-NMDA client to access module. The NMDA module can be used by a non-NMDA client to access
the conventional configuration datastores and the deprecated <get> the conventional configuration datastores and the deprecated <get>
operation to access nested "config false" data nodes. operation to access nested "config false" data nodes.
To create the temporary non-NMDA model from an NMDA model, the To create the temporary non-NMDA module from an NMDA module, the
following steps can be taken: following steps can be taken:
* Change the module name by appending "-state" to the original * Change the module name by appending "-state" to the original
module name. module name.
* Change the namespace by appending "-state" to the original * Change the namespace by appending "-state" to the original
namespace value. namespace value.
* Change the prefix by appending "-s" to the original prefix value. * Change the prefix by appending "-s" to the original prefix value.
skipping to change at line 2958 skipping to change at line 2965
4.26. Guidelines for Constructs Specific to YANG 1.1 4.26. Guidelines for Constructs Specific to YANG 1.1
The set of guidelines for YANG 1.1 will grow as operational The set of guidelines for YANG 1.1 will grow as operational
experience is gained with the new language features. This section experience is gained with the new language features. This section
contains an initial set of guidelines for YANG 1.1 language features. contains an initial set of guidelines for YANG 1.1 language features.
4.26.1. Importing Multiple Revisions 4.26.1. Importing Multiple Revisions
Standard modules SHOULD NOT import multiple revisions of the same Standard modules SHOULD NOT import multiple revisions of the same
module into a module. This MAY be done if independent definitions module into a module. This MAY be done if independent definitions
(e.g., enumeration typedefs) from specific revisions are needed in (e.g., "enumeration" typedefs) from specific revisions are needed in
the importing module. the importing module.
4.26.2. Using Feature Logic 4.26.2. Using Feature Logic
The YANG 1.1 feature logic is much more expressive than YANG 1.0. A The YANG 1.1 feature logic is much more expressive than YANG 1.0. A
"description" statement SHOULD describe the "if-feature" logic in "description" statement SHOULD describe the "if-feature" logic in
text, to help readers understand the module. text, to help readers understand the module.
YANG features SHOULD be used instead of the "when" statement, if YANG features SHOULD be used instead of the "when" statement, if
possible. Features are advertised by the server, and objects possible. Features are advertised by the server, and objects
skipping to change at line 3049 skipping to change at line 3056
organization will have their own way to identify published work that organization will have their own way to identify published work that
is considered to be stable and unpublished work that is considered to is considered to be stable and unpublished work that is considered to
be unstable. For example, in the IETF, an RFC is used for published be unstable. For example, in the IETF, an RFC is used for published
work, and an I-D is used for unpublished work. work, and an I-D is used for unpublished work.
4.28. Defining Standard Tags 4.28. Defining Standard Tags
[RFC8819] specifies a method for associating tags with YANG modules. [RFC8819] specifies a method for associating tags with YANG modules.
Tags may be defined and associated at design time, at implementation Tags may be defined and associated at design time, at implementation
time, or via user administrative control. Design-time tags are time, or via user administrative control. Design-time tags are
indicated using the module-tag extension statement. indicated using the module-tag "extension" statement.
A module MAY indicate, using module-tag extension statements, a set A module MAY indicate, using module-tag "extension" statements, a set
of tags that are to be automatically associated with it (i.e., not of tags that are to be automatically associated with it (i.e., not
added through configuration). added through configuration).
module example-module { module example-module {
namespace "https://example.com/yang/example"; namespace "https://example.com/yang/example";
prefix "ex"; prefix "ex";
//... //...
import module-tags { prefix tags; } import module-tags { prefix tags; }
tags:module-tag "ietf:some-new-tag"; tags:module-tag "ietf:some-new-tag";
skipping to change at line 3074 skipping to change at line 3081
} }
Authors can use existing standard tags or use new tags defined in the Authors can use existing standard tags or use new tags defined in the
model definition, as appropriate. For IETF modules, new tags MUST be model definition, as appropriate. For IETF modules, new tags MUST be
assigned in the IANA "IETF YANG Module Tags" registry within the assigned in the IANA "IETF YANG Module Tags" registry within the
"YANG Module Tags" registry group [IANA-TAGS]. "YANG Module Tags" registry group [IANA-TAGS].
4.29. Modeling Abstract Data Structures 4.29. Modeling Abstract Data Structures
For contexts where YANG is used to model abstract data structures For contexts where YANG is used to model abstract data structures
(e.g., protocol messages), the use of the "structure" extension (e.g., protocol messages), the use of the "structure" "extension"
statement [RFC8791] is RECOMMENDED compared to the "yang-data" statement [RFC8791] is RECOMMENDED compared to the "yang-data"
extension statement [RFC8040]. Examples of modules that rely upon "extension" statement [RFC8040]. Examples of modules that rely upon
the "structure" extension statement from [RFC8791] can be found in the "structure" "extension" statement from [RFC8791] can be found in
[RFC9132] or [RFC9195]. [RFC9132] or [RFC9195].
Abstract data structures can be augmented using the "augment- Abstract data structures can be augmented using the "augment-
structure" statement [RFC8791]. Examples of modules that augment structure" statement [RFC8791]. Examples of modules that augment
abstract data structures can be found in [RFC9244] and [RFC9362]. abstract data structures can be found in [RFC9244] and [RFC9362].
4.30. IANA-Maintained YANG Modules 4.30. IANA-Maintained YANG Modules
4.30.1. Context 4.30.1. Context
skipping to change at line 3135 skipping to change at line 3142
When one or multiple registries are available under the same registry When one or multiple registries are available under the same registry
group, it is RECOMMENDED to define an IANA-maintained YANG module for group, it is RECOMMENDED to define an IANA-maintained YANG module for
each registry. However, module designers MAY consider defining one each registry. However, module designers MAY consider defining one
single IANA-maintained YANG module that covers all registries if single IANA-maintained YANG module that covers all registries if
maintaining that single module is manageable (e.g., very few values maintaining that single module is manageable (e.g., very few values
are present or expected to be present for each registry). An example are present or expected to be present for each registry). An example
of such a module is documented in Section 5.2 of [RFC9132]. of such a module is documented in Section 5.2 of [RFC9132].
An IANA-maintained YANG module may use the "identityref" data type An IANA-maintained YANG module may use the "identityref" data type
approach (e.g., [RFC8675]) or an enumeration data type approach approach (e.g., [RFC8675]) or an "enumeration" data type approach
(e.g., [RFC9108]). See Section 4.11.1 for a guidance on which data (e.g., [RFC9108]). See Section 4.11.1 for a guidance on which data
type to use. The decision about which type to use should be made type to use. The decision about which type to use should be made
based upon specifics related to the intended use of the IANA- based upon specifics related to the intended use of the IANA-
maintained YANG module. For example, identities are useful if the maintained YANG module. For example, identities are useful if the
registry entries are organized hierarchically, possibly including registry entries are organized hierarchically, possibly including
multiple inheritances. The reasoning for the design choice MUST be multiple inheritances. The reasoning for the design choice MUST be
documented in the companion specification that registers an IANA- documented in the companion specification that registers an IANA-
maintained YANG module. For example, [RFC9244] defines an IANA- maintained YANG module. For example, [RFC9244] defines an IANA-
maintained YANG module that uses enumerations for the following maintained YANG module that uses enumerations for the following
reason: reason:
skipping to change at line 3217 skipping to change at line 3224
* https://www.iana.org/assignments/iana-pseudowire-types, and * https://www.iana.org/assignments/iana-pseudowire-types, and
* https://www.iana.org/assignments/iana-bfd-types. * https://www.iana.org/assignments/iana-bfd-types.
"IANA_FOO_URL" is used in the following to refer to such URLs. These "IANA_FOO_URL" is used in the following to refer to such URLs. These
URLs are expected to be sufficiently permanent and stable. URLs are expected to be sufficiently permanent and stable.
Whenever referencing a specific version of an IANA-maintained YANG Whenever referencing a specific version of an IANA-maintained YANG
module is needed, then URLs such as the following are used: module is needed, then URLs such as the following are used:
* https://www.iana.org/assignments/iana-bgp-l2-encaps * https://www.iana.org/assignments/iana-bgp-
l2-encaps@2022-09-20.yang
"IANA_FOO_URL_With_REV" is used in the following to refer to such "IANA_FOO_URL_With_REV" is used in the following to refer to such
URLs. URLs.
A template for IANA-maintained YANG modules is provided in A template for IANA-maintained YANG modules is provided in
Appendix C. Appendix C.
4.30.3. Guidance for Writing the IANA Considerations for RFCs Defining 4.30.3. Guidance for Writing the IANA Considerations for RFCs Defining
IANA-Maintained YANG Modules IANA-Maintained YANG Modules
skipping to change at line 3286 skipping to change at line 3294
with the naming conventions listed in Section 4.3.1, IANA with the naming conventions listed in Section 4.3.1, IANA
should check if guidance to generate legal identifiers was should check if guidance to generate legal identifiers was
supplied in the RFC that specified the initial version of the supplied in the RFC that specified the initial version of the
module. If no such guidance is available, IANA should check module. If no such guidance is available, IANA should check
the latest revision of the IANA-maintained YANG module for the latest revision of the IANA-maintained YANG module for
similar patterns. If all else fails, IANA should seek advice similar patterns. If all else fails, IANA should seek advice
from relevant registry experts (e.g., designated experts for a from relevant registry experts (e.g., designated experts for a
registry using the Expert Review policy (Section 4.5 of registry using the Expert Review policy (Section 4.5 of
[RFC8126]) or responsible area director). [RFC8126]) or responsible area director).
* A note that unassigned or reserved values must not be present in * A note whether unassigned or reserved values should be present in
the IANA-maintained YANG module. the IANA-maintained YANG module. If no instruction is provided,
unassigned or reserved values must not be present in the IANA-
maintained YANG module.
* An instruction whether experimental values should be included in * An instruction whether experimental values should be included in
the IANA-maintained YANG module. If no instruction is provided, the IANA-maintained YANG module. If no instruction is provided,
experimental values MUST NOT be listed in the IANA-maintained YANG experimental values MUST NOT be listed in the IANA-maintained YANG
module. module.
* An instruction about how to generate the "revision" statement. * An instruction about how to generate the "revision" statement. If
no instruction is provided, default actions provided in
Section 4.30 will be followed.
A template for the IANA Considerations is provided in A template for the IANA Considerations is provided in
Section 4.30.3.1 for IANA-maintained YANG modules with identities and Section 4.30.3.1 for IANA-maintained YANG modules with identities and
Section 4.30.3.2 for IANA-maintained YANG modules with enumerations. Section 4.30.3.2 for IANA-maintained YANG modules with enumerations.
Authors may modify the template to reflect specifics of their modules Authors may modify the template to reflect specifics of their modules
(e.g., multiple registries can be listed for a single IANA-maintained (e.g., multiple registries can be listed for a single IANA-maintained
YANG module, no explicit description (or name) field is listed under YANG module, no explicit description (or name) field is listed under
the authoritative IANA registry, or the name does not comply with the authoritative IANA registry, or the name does not comply with
YANG naming conventions (Section 4.3.1)). YANG naming conventions (Section 4.3.1)).
skipping to change at line 3413 skipping to change at line 3425
"IpSec tunnel mode encapsulation."; "IpSec tunnel mode encapsulation.";
reference reference
"RFC 4301: Security Architecture for the Internet Protocol"; "RFC 4301: Security Architecture for the Internet Protocol";
} }
The templates in the following subsections are to be considered in The templates in the following subsections are to be considered in
addition to the required information that is provided in Section 3.8. addition to the required information that is provided in Section 3.8.
4.30.3.1. Template for IANA-Maintained YANG Modules with Identities 4.30.3.1. Template for IANA-Maintained YANG Modules with Identities
This template ends with a section labeled "OPTIONAL". Any text in
this section that needs to be customized should be included in the
template. Text that does not require customization should be omitted
from the IANA Considerations section.
<CODE BEGINS> <CODE BEGINS>
This document defines the initial version of the IANA-maintained This document defines the initial version of the IANA-maintained
"iana-foo" YANG module. The most recent version of the YANG module "iana-foo" YANG module. The most recent version of the YANG module
is available from the "YANG Parameters" registry group is available from the "YANG Parameters" registry group
[IANA-YANG-PARAMETERS]. [IANA-YANG-PARAMETERS].
IANA is requested to add this note to the registry: IANA is requested to add this note to the registry:
New values must not be directly added to the "iana-foo" YANG New values must not be directly added to the "iana-foo" YANG
module. They must instead be added to the "foo" registry. module. They must instead be added to the "foo" registry.
IANA is requested to add this note to [reference-to-the-iana-foo-
registry]:
When this registry is modified, the YANG module "iana-foo"
[IANA_FOO_URL] must be updated as defined in RFC IIII.
When a value is added to the "foo" registry, a new "identity" When a value is added to the "foo" registry, a new "identity"
statement needs to be added to the "iana-foo" YANG module. The name statement needs to be added to the "iana-foo" YANG module.
of the "identity" MUST be the name as provided in the registry. The name of the "identity" MUST be the name as provided in the
The "identity" statement should have the following registry. The "identity" statement should have the following
substatements defined: substatements defined:
"base": Contains 'name-base-identity-defined-in-foo'. "base": Contains 'name-base-identity-defined-in-foo'.
"status": Include only if a registration has been deprecated or "status": Include only if a registration has been deprecated or
obsoleted. IANA "deprecated" maps to YANG status obsoleted. IANA "deprecated" maps to YANG status
"deprecated", and IANA "obsolete" maps to YANG status "deprecated", and IANA "obsolete" maps to YANG status
"obsolete". "obsolete".
"description": Replicates the description from the registry. "description": Replicates the description from the registry.
"reference": Replicates the reference(s) from the registry with "reference": Replicates the reference(s) from the registry with
the title of the document(s) added. the title of the document(s) added.
Unassigned or reserved values are not present in the module. -- OPTIONAL:
When the "iana-foo" YANG module is updated, a new "revision"
statement with a unique revision date must be added in front of the
existing "revision" statements. The "revision" statement MUST
contain both "description" and "reference" substatements as follows.
The "description" substatement captures what changed in the -- Include only text that needs to be customized for the module.
revised version. Typically, the description enumerates the changes -- Text that does not require customization should be
such as udpates to existing entries (e.g., update a description or -- omitted.
a reference) or notes which identities were added or had their status
changed (e.g., deprecated, discouraged, or obsoleted).
-- When such a description is not feasible, the description varies -- Notes tagged with "--" include instructions for authors. These
-- on how the update is triggered. -- notes must not be copied.
-- If the update is triggered by an RFC, insert this text: Unassigned and Reserved Values:
The "description" substatement should include this text: -- To be completed only if unassigned and/or reserved values
"Applied updates as specified by RFC XXXX.". -- (which may include experimental values) should be included
-- in the module. These values are typically not included.
-- If the update is triggered following other IANA registration Description Substatements:
-- policy (Section 4 of [RFC8126]) but not all the values in the
-- registry are covered by the same policy, insert this text:
The "description" substatement should include this text: -- To be completed only if the default actions described in
"Applied updates as specified by the registration policy -- Section 5.3.2 of RFC 9907 are to be overridden.
<Some_IANA_policy>". -- Specify whether instructions apply to "revision" statements,
-- "identity" statements, or both.
The "reference" substatement points specifically to the published Reference Substatements:
module (i.e., IANA_FOO_URL_With_REV). It may also point to an
authoritative event triggering the update to the YANG module. In all
cases, this event is cited from the underlying IANA registry. If the
update is triggered by an RFC, that RFC must also be included in
the "reference" substatement.
-- If a name in the IANA registry does not comply with the -- To be completed only if the default actions described in
-- YANG naming conventions, add details how IANA can generate -- Section 5.3.2 of RFC 9907 are to be overridden.
-- legal identifiers. For example, if the name begins with -- Specify whether instructions apply to "revision" statements,
-- a number, indicate a preference to spell out the number when -- "identity" statements, or both.
-- used as an identifier.
IANA is requested to add this note to [reference-to-the-iana-foo- Naming Considerations:
registry]:
When this registry is modified, the YANG module "iana-foo" -- If a name in the IANA registry does not comply with the
[IANA_FOO_URL] must be updated as defined in RFC IIII. -- YANG naming conventions, add details how IANA can generate
-- legal identifiers. For example, if the name begins with
-- a number, indicate a preference to spell out the number when
-- used as an identifier.
<CODE ENDS> <CODE ENDS>
4.30.3.2. Template for IANA-Maintained YANG Modules with Enumerations 4.30.3.2. Template for IANA-Maintained YANG Modules with Enumerations
<CODE BEGINS> This template ends with a section labeled "OPTIONAL". Any text in
this section that needs to be customized should be included in the
template. Text that does not require customization should be omitted
from the IANA Considerations section.
This document defines the initial version of the IANA-maintained <CODE BEGINS>
"iana-foo" YANG module. The most recent version of the YANG module
is available from the "YANG Parameters" registry group
[IANA-YANG-PARAMETERS].
IANA is requested to add this note to the registry: This document defines the initial version of the IANA-maintained
"iana-foo" YANG module. The most recent version of the YANG module
is available from the "YANG Parameters" registry group
[IANA-YANG-PARAMETERS].
New values must not be directly added to the "iana-foo" YANG IANA is requested to add this note to the registry:
module. They must instead be added to the "foo" registry.
When a value is added to the "foo" registry, a new "enum" statement New values must not be directly added to the "iana-foo" YANG
must be added to the "iana-foo" YANG module. The "enum" statement, module. They must instead be added to the "foo" registry.
and substatements thereof, should be defined:
"enum": Replicates a name from the registry. When a value is added to the "foo" registry, a new "enum" statement
must be added to the "iana-foo" YANG module. The "enum" statement,
and substatements thereof, should be defined:
"value": Contains the decimal value of the IANA-assigned "enum": Replicates a name from the registry.
value.
"status": Is included only if a registration has been "value": Contains the decimal value of the IANA-assigned
deprecated or obsoleted. IANA "deprecated" maps value.
to YANG status "deprecated", and IANA "obsolete"
maps to YANG status "obsolete".
"description": Replicates the description from the registry. "status": Is included only if a registration has been
deprecated or obsoleted. IANA "deprecated" maps
to YANG status "deprecated", and IANA "obsolete"
maps to YANG status "obsolete".
"reference": Replicates the reference(s) from the registry with "description": Replicates the description from the registry.
the title of the document(s) added.
Unassigned or reserved values are not present in the module. "reference": Replicates the reference(s) from the registry.
References to documents should also inlcude titles.
When the "iana-foo" YANG module is updated, a new "revision" -- OPTIONAL:
statement with a unique revision date needs to be added in front of
the existing "revision" statements. The "revision" statement MUST
contain both "description" and "reference" substatements as follows.
The "description" substatement captures what changed in the -- Include only text that needs to be customized for the module.
revised version. Typically, the description enumerates the changes -- Text that does not require customization should be
such as udpates to existing entries (e.g., update a description or -- omitted.
a reference) or notes which "enums" were added or had their status
changed (e.g., deprecated, discouraged, or obsoleted).
-- When such a description is not feasible, the description varies -- Notes tagged with "--" include instructions for authors. These
-- on how the update is triggered. -- notes must not be copied.
-- If the update is triggered by an RFC, insert this text: Unassigned and Reserved Values:
The "description" substatement should include this text: -- To be completed only if unassigned and/or reserved values
"Applied updates as specified by RFC XXXX.". -- (which may include experimental values) should be included
-- in the module. These values are typically not included.
-- If the update is triggered following other IANA registration Description Substatements:
-- policy (Section 4 of [RFC8126]) but not all the values in the
-- registry are covered by the same policy, insert this text:
The "description" substatement should include this text: -- To be completed only if the default actions described in
"Applied updates as specified by the registration policy -- Section 5.3.2 of RFC 9907 are to be overridden.
<Some_IANA_policy>". -- Specify whether instructions apply to "revision" statements, "enum"
-- statements, or both.
The "reference" substatement points specifically to the published Reference Substatements:
module (i.e., IANA_FOO_URL_With_REV). It may also point to an
authoritative event triggering the update to the YANG module. In all
cases, this event is cited from the underlying IANA registry. If the
update is triggered by an RFC, that RFC must also be included in
the "reference" substatement.
-- If a name in the IANA registry does not comply with the -- To be completed only if the default actions described in
-- YANG naming conventions, add details how IANA can generate -- Section 5.3.2 of RFC 9907 are to be overridden.
-- legal identifiers. For example, if the name begins with -- Specify whether instructions apply to "revision" statements, "enum"
-- a number, indicate a preference to spell out the number when -- statements, or both.
-- used as an identifier.
IANA is requested to add this note to [reference-to-the-iana-foo- Naming Considerations:
registry]:
When this registry is modified, the YANG module "iana-foo" -- If a name in the IANA registry does not comply with the
[IANA_FOO_URL] must be updated as defined in RFC IIII. -- YANG naming conventions, add details how IANA can generate
-- legal identifiers. For example, if the name begins with
-- a number, indicate a preference to spell out the number when
-- used as an identifier.
<CODE ENDS> <CODE ENDS>
5. IANA Considerations 5. IANA Considerations
5.1. YANG Modules 5.1. YANG Modules
The following registration in the "ns" registry of the "IETF XML The following registration in the "ns" registry of the "IETF XML
Registry" registry group [RFC3688] was detailed in [RFC8407]. IANA Registry" registry group [RFC3688] was detailed in [RFC8407]. IANA
has updated this registration to reference this document. has updated this registration to reference this document.
URI: urn:ietf:params:xml:ns:yang:ietf-template URI: urn:ietf:params:xml:ns:yang:ietf-template
skipping to change at line 3622 skipping to change at line 3628
For the references of the "YANG Module Names" registry under the For the references of the "YANG Module Names" registry under the
"YANG Parameters" registry group, IANA has updated [RFC8407] to this "YANG Parameters" registry group, IANA has updated [RFC8407] to this
document, as it contains the template necessary for registration in document, as it contains the template necessary for registration in
Appendix B. Appendix B.
5.3. IANA-Maintained YANG Modules 5.3. IANA-Maintained YANG Modules
IANA should refer to Section 4.30.3 for information necessary to IANA should refer to Section 4.30.3 for information necessary to
populate "revision" statements and "identity" and "enum" populate "revision" statements and "identity" and "enum"
substatements in IANA-maintained YANG modules. These considerations substatements in IANA-maintained YANG modules.
cover both the creation and maintenance of an IANA-mainatined module.
In particular, the following should be noted: These considerations cover both the creation and maintenance of an
IANA-mainatined YANG module, and they include both instructions
applicable to all IANA-maintained YANG modules and instructions that
can be customized by module creators.
5.3.1. Requirements for All Modules
In particular, the following instructions should apply to all
modules:
* When an underlying registration is deprecated or obsoleted, a * When an underlying registration is deprecated or obsoleted, a
corresponding "status" substatement should be added to the corresponding "status" substatement should be added to the
identity or enumeration statement. identity or enumeration statement.
* The "reference" substatement should point specifically to the * The "reference" substatement in the "revision" statement should
published module (i.e., IANA_FOO_URL_With_REV). When the point specifically to the published module (i.e.,
registration is triggered by an RFC, that RFC must also be IANA_FOO_URL_With_REV). When the registration is triggered by an
included in the "reference" substatement. It may also point to an RFC, that RFC must also be included in the "reference"
authoritative event triggering the update to the YANG module. In substatement. It may also point to an authoritative event
all cases, the event is cited from the underlying IANA registry. triggering the update to the YANG module. In all cases, the event
is cited from the underlying IANA registry.
* References to documents should include titles.
In addition, when the module is published, IANA must add the In addition, when the module is published, IANA must add the
following notes to: following notes to:
The YANG Module Names registry: The YANG Module Names registry:
New values must not be directly added to the "iana-foo" YANG New values must not be directly added to the "iana-foo" YANG
module. They must instead be added to the "foo" registry. module. They must instead be added to the "foo" registry.
The underlying registry: The underlying registry:
When this registry is modified, the YANG module "iana-foo" When this registry is modified, the YANG module "iana-foo"
[IANA_FOO_URL] must be updated as defined in RFC IIII. [IANA_FOO_URL] must be updated as defined in RFC IIII.
6. Operations and Manageability Considerations 5.3.2. Requirements Subject to Customization
Unless the creators of an IANA-maintained YANG module specify
otherwise in their document's IANA Considerations section, the
following instructions will apply:
* Unassigned and reserved values (including experimental values)
will be omitted from the module.
* The "reference" statement in an "identity" or "enum" substatement
should mirror the underlying registry. It may point to contact
names as well as documents.
* In a "revision" statement, the "description" substatement captures
what changed in the revised version. Typically, the "description"
enumerates changes such as updates to existing entries (e.g.,
update a "description" or a "reference") or notes which identities
were added or had their status changed (e.g., deprecated,
discouraged, or obsoleted).
When such a description is not feasible, the description varies in
accordance with the trigger for the update.
If the update is triggered by an RFC, the "description" substatement
should include or consist of this text:
"Applied updates as specified by RFC XXXX."
If the registration policy for the registry does not require RFC
publication (Section 4 of [RFC8126]), insert this text:
"Applied updates as specified by the registration policy
<Some_IANA_policy>".
6. Operational Considerations
Although the document focuses on YANG data modeling language Although the document focuses on YANG data modeling language
guidance, the document does not define a protocol or a protocol guidance, the document does not define a protocol or a protocol
extension. As such, there are no new operations or manageability extension. As such, there are no new operations or manageability
requirements introduced by this document. requirements introduced by this document.
7. Security Considerations 7. Security Considerations
This document defines guidelines for NETCONF or RESTCONF content This document defines guidelines for NETCONF or RESTCONF content
defined with the YANG data modeling language. It does not introduce defined with the YANG data modeling language. It does not introduce
skipping to change at line 4076 skipping to change at line 4127
// import ietf-yang-types { prefix yang; } // import ietf-yang-types { prefix yang; }
// import ietf-inet-types { prefix inet; } // import ietf-inet-types { prefix inet; }
// identify the IETF working group if applicable // identify the IETF working group if applicable
organization organization
"IETF your-wg-name (Expanded WG Name) Working Group"; "IETF your-wg-name (Expanded WG Name) Working Group";
// update this contact statement with your info // update this contact statement with your info
contact contact
"WG Web: http://datatracker.ietf.org/wg/your-wg-name "WG Web: https://datatracker.ietf.org/wg/your-wg-name
WG List: YOUR-WG-NAME <mailto:your-wg-name@ietf.org> WG List: YOUR-WG-NAME <mailto:your-wg-name@ietf.org>
Editor: your-name Editor: your-name
<mailto:your-email@example.com>"; <mailto:your-email@example.com>";
// replace the first sentence in this description statement. // replace the first sentence in this "description" statement.
// replace the copyright notice with the most recent // replace the copyright notice with the most recent
// version, if it has been updated since the publication // version, if it has been updated since the publication
// of this document. // of this document.
description description
"This module defines a template for other YANG modules. "This module defines a template for other YANG modules.
Copyright (c) <insert year> IETF Trust and the persons Copyright (c) <insert year> IETF Trust and the persons
identified as authors of the code. All rights reserved. identified as authors of the code. All rights reserved.
skipping to change at line 4107 skipping to change at line 4158
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
All revisions of IETF and IANA published modules can be found All revisions of IETF and IANA published modules can be found
at the YANG Parameters registry group at the YANG Parameters registry group
(https://www.iana.org/assignments/yang-parameters). (https://www.iana.org/assignments/yang-parameters).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
// replace 'date-revision' with the module publication date // RFC Ed: replace 'date-revision' with the module publication date
// the format is (YYYY-MM-DD) // the format is (YYYY-MM-DD)
// RFC Ed.: replace XXXX with actual RFC number and remove // replace XXXX with actual RFC number and remove
// this note // this note
revision date-revision { revision date-revision {
description description
"What changed in this revision."; "What changed in this revision.";
reference reference
"RFC XXXX: <Replace With Document Title>"; "RFC XXXX: <Replace With Document Title>";
} }
// Authors: Update with the RFC number and title // Authors: Replace RFC IIII with the RFC number and title
// of the RFC that defined the initial version of // of the RFC that defined the initial version of
// the module and remove this note // the module and remove this note
revision date-initial { revision date-initial {
description description
"Initial version."; "Initial version.";
reference reference
"RFC IIII: <Replace With Document Title>"; "RFC IIII: <Replace With Document Title>";
} }
 End of changes. 106 change blocks. 
205 lines changed or deleted 256 lines changed or added

This html diff was produced by rfcdiff 1.48.