YANG Configuration Templates
draft-tt-netmod-yang-config-templates-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Kent Watsen , Qiufang Ma , Deepak Rajaram | ||
| Last updated | 2026-07-03 | ||
| Replaces | draft-wills-netmod-yang-config-templates | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Yang Validation | 0 errors, 0 warnings | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-tt-netmod-yang-config-templates-03
Network Modeling K. Watsen
Internet-Draft Watsen Networks
Intended status: Standards Track Q. Ma
Expires: 4 January 2027 Huawei
D. Rajaram
Nokia
3 July 2026
YANG Configuration Templates
draft-tt-netmod-yang-config-templates-03
Abstract
NETCONF and RESTCONF protocols provide programmatic interfaces for
accessing configuration data modeled by YANG. This document defines
the use of a YANG-based configuration template mechanism whereby
configuration data can be defined in one or more templates and
applied repeatedly. This avoids the redundant definition of
identical configuration and ensures the consistency of it, thus
allowing configuration data to be managed more conveniently and
efficiently.
Discussion Venues
This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the Network Modeling
Working Group mailing list (netmod@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/netmod/.
Source for this draft and an issue tracker can be found at
https://github.com/QiufangMa/template-mechanism.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Watsen, et al. Expires 4 January 2027 [Page 1]
Internet-Draft template July 2026
This Internet-Draft will expire on 4 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Editorial Note (To be removed by RFC Editor) . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Defining and Managing Templates . . . . . . . . . . . . . 4
3.2. Applying Templates . . . . . . . . . . . . . . . . . . . 5
3.3. Producing the Intended Datastore . . . . . . . . . . . . 5
3.4. Pattern Matching in Templates . . . . . . . . . . . . . . 6
3.5. Off-box Template Expansion . . . . . . . . . . . . . . . 6
4. Configuration Template Solution . . . . . . . . . . . . . . . 6
4.1. Defining Templates . . . . . . . . . . . . . . . . . . . 6
4.1.1. Template Definition with Pattern Matching . . . . . . 7
4.2. Applying Templates . . . . . . . . . . . . . . . . . . . 8
4.2.1. The "apply-templates" Metadata . . . . . . . . . . . 8
4.2.2. Creating, editing and deleting the "apply-templates"
metadata . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Overriding Templates . . . . . . . . . . . . . . . . . . 12
4.4. Expanding Templates . . . . . . . . . . . . . . . . . . . 13
4.5. Deletion of Templates . . . . . . . . . . . . . . . . . . 14
4.6. Validity of Templates . . . . . . . . . . . . . . . . . . 14
5. Interaction with NMDA datastores . . . . . . . . . . . . . . 15
6. Interaction with Non-NMDA datastores . . . . . . . . . . . . 15
7. The "ietf-config-template" YANG Module . . . . . . . . . . . 15
7.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 15
7.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 16
8. Operational Considerations . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . 18
10.2. The "YANG Module Names" Registry . . . . . . . . . . . . 18
Watsen, et al. Expires 4 January 2027 [Page 2]
Internet-Draft template July 2026
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. Requirement Implementation Status . . . . . . . . . 20
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction
This document considers the case of a datastore that contains
multiple subtrees with similar or identical nodes within them, such
that the datastore contains repetitive data with limited variation.
If a client has to repeatedly configure the same nodes for each
subtree, this can become complex and error-prone.
This document proposes a solution to improve this, called
"Configuration Templates". A configuration template is a fragment of
configuration that the server is instructed to replicate multiple
times to generate copies of the configuration. This allows
repetitive subtrees of configuration to be written only once, in the
template. When needed, individual instantiations of a template can
override the values of nodes, or add new instance-specific nodes.
NMDA [RFC8342] allows the configuration templates to be defined in
<running> and expanded in <intended>, but it does not specify details
about how configuration templates could be created and applied.
This document defines the use of configuration templates in the
context of YANG-driven network management protocols such as NETCONF
[RFC6241] and RESTCONF [RFC8040]. Configuration templates can be
used with any YANG data model, this document doesn't make any
assumption on the YANG data model design, i.e., it does not rely on a
shared profile/group being defined in the YANG data model.
1.1. Editorial Note (To be removed by RFC Editor)
Note to the RFC Editor: This section is to be removed prior to
publication.
This document contains placeholder values that need to be replaced
with finalized values at the time of publication. This note
summarizes all of the substitutions that are needed. No other RFC
Editor instructions are specified elsewhere in this document.
Please apply the following replacements:
* XXXX --> the assigned RFC number for this draft
Watsen, et al. Expires 4 January 2027 [Page 3]
Internet-Draft template July 2026
* 2026-07-03 --> the actual date of the publication of this document
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The meanings of the symbols in tree diagrams are defined in
[RFC8340].
This document uses the terminology defined in Section 3 of [RFC7950]
and Section 3 of [RFC8342].
This document uses the following terminology in [RFC6241]:
* configuration data
Besides, this document defines the following terminology:
configuration template: A chunk of reusable configuration data that
could be applied to the configuration repeatedly, in order to
simplify the delivery of network configuration and ensure the
consistency of it. A configuration template is referred to
interchangeably as "template" or "YANG template" throughout this
document.
3. Requirements
This section describes requirements that the configuration templates
solution must satisfy. A general theme of the configuration template
work is to come up with a "Minimal Viable Product (MVP)" that
delivers a baseline solution with essential functionality but avoids
excessive complexity. More advanced features could be considered as
extensions in future work.
3.1. Defining and Managing Templates
Templates can be defined with any YANG module. They contain nodes of
configuration data, and are stored in the running datastore of the
server after creation.
A client can view and manipulate a template in <running>. System may
generate a template in <system> ([I-D.ietf-netmod-system-config]).
In this sense, a template and its contents behave like any other
configuration data.
Watsen, et al. Expires 4 January 2027 [Page 4]
Internet-Draft template July 2026
3.2. Applying Templates
A template can be applied to zero or more nodes in the running
datastore. Each node can have zero or more templates applied to it,
and the order specified by the client determines the precedence with
which templates are applied within that node.
Templates can be applied at multiple nodes in the hierachy. When
viewing the contents of <running>, there is a mechanism to see which
templates have been applied to each node, and in which order.
3.3. Producing the Intended Datastore
The server's intended datastore is the result of combining all the
applications of templates together with non-template configuration
(i.e., configuration explicitly created by clients rather than
derived from applied templates) in <running> and <system> (see
[I-D.ietf-netmod-system-config]). This is called template expansion.
The intended configuration inside a subtree is the result of taking
the relevant contents of every template applied to the subtree's root
node and its ancestors, and combining it with the (non-template) data
nodes inside the subtree.
A node inside a subtree may be present in multiple templates that
have been applied, and/or it may be present as non-template
configuration inside the subtree. The requirements for template
expansion are as follows:
* The value of a node in <intended> is determined by using
precedence rule to decide where to take the value from.
* Non-template configuration always has the highest precedence.
* When templates are applied to multiple ancestors, the innermost
ancestor takes precedence.
* When multiple templates are applied to a particular node, the
order of application (as indicated by the client when applying the
templates) determines the precedence within that node.
Whenever the contents of a template is updated in <running> or
<system>, the result of template expansion appears in <intended>.
Watsen, et al. Expires 4 January 2027 [Page 5]
Internet-Draft template July 2026
3.4. Pattern Matching in Templates
The configuration inside a template definition can contain values for
list keys that are simple regular expressions, using a limited subset
of regular expression syntax. This controls which list entries that
particular subtree of the template takes effect for when the template
is applied.
An example of this would be to have a template that is applied to a
top-level "interfaces" container, but the template only takes effect
for certain interface names that match the regular expression.
3.5. Off-box Template Expansion
If the client knows the complete contents of <running> and <system>,
which include non- template configuration, template definitions and
template applications, the client must be able to calculate the
result of template expansion, i.e., the contents of <intended>.
In other words, the outcome of template expansion depends solely on
the contents of running and system datastores.
4. Configuration Template Solution
4.1. Defining Templates
A configuration template must first be defined before it can be
applied (see Section 4.2). The creation, modification, and deletion
of configuration templates are achieved by network management
operations via NETCONF or RESTCONF protocols. The contents of the
configuration template must be an instantiated chunk of data starting
from any level node in the hierarchies of any YANG data model.
For example, Figure 1 provides an interface configuration template
named "base-interface":
Watsen, et al. Expires 4 January 2027 [Page 6]
Internet-Draft template July 2026
<templates xmlns="urn:ietf:params:xml:ns:yang:ietf-config-template">
<template>
<id>base-interface</id>
<content>
<interfaces xmlns="urn:example:interface">
<interface>
<enabled>true</enabled>
<mtu>65536</mtu>
<description>default provisioned interface</description>
</interface>
</interfaces>
</content>
</template>
</templates>
Figure 1: Example of An Interface Template
The YANG data model of configuration templates is defined in
Section 7.
4.1.1. Template Definition with Pattern Matching
To allow a single template to apply to multiple instances with
similar naming conventions without explicit replication, a regular
expression string may be used within key leafs to restrict which list
entries a template takes effect for. It MUST NOT be used on any
nodes other than a list key with built-in type "string", or types
derived from "string".
Any regular expression pattern MUST conform to [RFC9485], which
defines a subset of XML Schema Definition (XSD) regular expressions
[XSD-TYPES].
For example, Figure 2 provides an interface configuration template
that sets "type" as ethernetCsmacd and "mtu" as 1500 for all
interfaces names match the pattern "eth.*", i.e., starting with the
prefix "eth":
Watsen, et al. Expires 4 January 2027 [Page 7]
Internet-Draft template July 2026
<templates xmlns="urn:ietf:params:xml:ns:yang:ietf-config-template">
<template>
<id>ethernet-interface</id>
<content>
<interfaces xmlns="urn:example:interface">
<interface>
<name>eth.*</name>
<type>ethernetCsmacd</type>
<mtu>1500</mtu>
<description>default provisioned ethernet interface</description>
</interface>
</interfaces>
</content>
</template>
</templates>
Figure 2: Example of An Interface Template with Pattern Matching
4.2. Applying Templates
For each configuration node, including container, list, anydata,
anyxml, leaf-list, and leaf, one or more templates can be applied.
This causes configuration from one or more templates to be merged
with explicitly provided configuration data to produce a final set of
configuration that is intended to be applied by the server. Any
update to the applied templates will be reflected in the merging
result.
4.2.1. The "apply-templates" Metadata
Template application is indicated using the "apply-templates"
metadata annotation [RFC7952]. The value of this is a list of space-
separated template identifiers. The order of appearance of the
template identifiers in the list determines their precedence when
producing the merging result. If the template is applied to a node
in the data tree, the metadata object is added to that specific node.
The encoding of "apply-templates" metadata object follows the way
defined in Section 5 of [RFC7952].
For example, Figure 3 provides the interface configuration with the
container node "interfaces" applying the templates "ethernet-
interface" and "base-interface", defined in Figure 2 and Figure 1
respectively:
Watsen, et al. Expires 4 January 2027 [Page 8]
Internet-Draft template July 2026
<interfaces xmlns="urn:example:interface"
xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-config-template"
ct:apply-templates="ethernet-interface base-interface">
<interface>
<name>loopback0</name>
</interface>
<interface>
<name>eth0</name>
</interface>
<interface>
<name>eth1</name>
</interface>
</interfaces>
Figure 3: An Example of Applying Templates
And the above interface configuration renders the expanded
configuration shown in Figure 4:
<interfaces xmlns="urn:example:interface">
<interface>
<name>loopback0</name>
<enabled>true</enabled>
<mtu>65536</mtu>
<description>default provisioned interface</description>
</interface>
<interface>
<name>eth0</name>
<enabled>true</enabled>
<type>ethernetCsmacd</type>
<mtu>1500</mtu>
<description>default provisioned ethernet interface</description>
</interface>
<interface>
<name>eth1</name>
<enabled>true</enabled>
<type>ethernetCsmacd</type>
<mtu>1500</mtu>
<description>default provisioned ethernet interface</description>
</interface>
</interfaces>
Figure 4: Template Expansion
Watsen, et al. Expires 4 January 2027 [Page 9]
Internet-Draft template July 2026
4.2.2. Creating, editing and deleting the "apply-templates" metadata
The "apply-templates" metadata annotation may be modified by the
client by specifying a different value in subsequent operations. Any
modification to this annotation MUST provide the complete, updated
list of template identifiers on the target node, rather than merging
with or appending to it. There are three cases when modifying the
"apply-templates" annotation:
* The "apply-templates" annotation is specified and the value is
non- empty (i.e. a list of templates to apply to the node). The
"apply- templates" metadata is changed to match the exact value in
the request.
* The "apply-templates" annotation is specified and the value is
either empty or contains only whitespace. The "apply-templates"
metadata is removed and thus no templates are applied to the node.
* The "apply-templates" annotation is not specified. The "apply-
templates" metadata currently present on the node (if any) is
unchanged.
For example, Figure 5 creates two interface entries named "loopback0"
and "eth0" and applies template "base-interface" to the interfaces
container:
<interfaces xmlns="urn:example:interface"
xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-config-template"
ct:apply-templates="base-interface">
<interface>
<name>loopback0</name>
</interface>
<interface>
<name>eth0</name>
</interface>
</interfaces>
Figure 5: An Initial Template Application Example
A subsequent request in Figure 6 also applies template "ethernet-
interface" to the interfaces container:
<interfaces xmlns="urn:example:interface"
ct:apply-templates="ethernet-interface base-interface"/>
Figure 6: Request to Prepend a Second Template
After this request, <running> is as shown in Figure 7:
Watsen, et al. Expires 4 January 2027 [Page 10]
Internet-Draft template July 2026
<interfaces xmlns="urn:example:interface"
xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-config-template"
ct:apply-templates="ethernet-interface base-interface">
<interface>
<name>loopback0</name>
</interface>
<interface>
<name>eth0</name>
</interface>
</interfaces>
Figure 7: Running Contents After Multiple Template Application
Figure 8 adds a new interface list entry, and leaves the applied
templates unchanged:
<interfaces xmlns="urn:example:interface">
<interface>
<name>eth1</name>
</interface>
</interfaces>
Figure 8: Request to Add a New Interface Entry
After this request, <running> is as shown in Figure 9.
<interfaces xmlns="urn:example:interface"
xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-config-template"
ct:apply-templates="ethernet-interface base-interface">
<interface>
<name>loopback0</name>
</interface>
<interface>
<name>eth0</name>
</interface>
<interface>
<name>eth1</name>
</interface>
</interfaces>
Figure 9: Running Contents After Interface Addition
Finally, this request deletes all the templates, and leaves the list
entries unchanged:
Watsen, et al. Expires 4 January 2027 [Page 11]
Internet-Draft template July 2026
<interfaces xmlns="urn:example:interface"
xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-config-template"
ct:apply-templates="">
<interface>
<name>loopback0</name>
</interface>
<interface>
<name>eth0</name>
</interface>
<interface>
<name>eth1</name>
</interface>
</interfaces>
Figure 10: Request to Clear All Applied Templates
After this request, <running> is as follows:
<interfaces xmlns="urn:example:interface">
<interface>
<name>loopback0</name>
</interface>
<interface>
<name>eth0</name>
</interface>
<interface>
<name>eth1</name>
</interface>
</interfaces>
Figure 11: Running Contents After Removing Template Applications
4.3. Overriding Templates
The client may want to to override some configuration in a template
when it is applied to a particular node in read-write datastores
(e.g., <running> or <candidate>). The client can achieve this by
providing the desired value at the corresponding level when applying
the template. Configuration explicitly provided by the client always
takes precedence over the same node defined in template.
A template node can be overriden by having its value changed, but it
can't be deleted.
Figure 12 provides an example of overriding a node in a template, a
client may configure physically present interfaces "eth0" and "eth1"
inheriting the template defined in Figure 1, but the "mtu" value of
"eth1" needs to be 9122:
Watsen, et al. Expires 4 January 2027 [Page 12]
Internet-Draft template July 2026
<interfaces xmlns="urn:example:interface"
xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-config-template"
ct:apply-templates="base-interface">
<interface>
<name>eth0</name>
</interface>
<interface>
<name>eth1</name>
<mtu>9122</mtu>
</interface>
</interfaces>
Figure 12: Example of Explicit Configuration Overriding a Template
And the above interface configuration renders the expanded
configuration shown in Figure 13.
<interfaces xmlns="urn:example:interface">
<interface>
<name>eth0</name>
<enabled>true</enabled>
<mtu>65536</mtu>
<description>default provisioned interface</description>
</interface>
<interface>
<name>eth1</name>
<enabled>true</enabled>
<mtu>9122</mtu>
<description>default provisioned interface</description>
</interface>
</interfaces>
Figure 13: Expanded Configuration Result with Overridden MTU
4.4. Expanding Templates
When a configuration template is applied to a node in the data tree,
it acts as if the configuration defined in the template is merged
with the configuration provided explicitly at the corresponding level
in the data tree, with the explicitly provided configuration taking
precedence.
the process of expanding templates to derive <intended> is
deterministic and depends solely on the contents of <running>. The
process rules are as follows:
Watsen, et al. Expires 4 January 2027 [Page 13]
Internet-Draft template July 2026
* The value of a node in <intended> after template expansion is
determined by using precedence to decide where to take the value
from.
* Non-template configuration always has the highest precedence.
* When templates are applied to multiple ancestors, the innermost
ancestor takes precedence.
* When multiple templates are applied to a particular node, the
order of application (as indicated by the client when applying the
templates) determines the precedence within that node.
If a client has knowledge of the complete contents of <running> and
<system>, it can calculate the exact result of template expansion,
independent of the server's operational state.
Whenever the contents of an applied template is updated in <running>
or <system>, the result of template expansion appears in <intended>.
4.5. Deletion of Templates
A configuration template can not be deleted if it is currently
actively applied to any data node. When a client attempts to delete
a template definition from read-write datastores (e.g., <running> or
<candidate>) that is in use, the server MUST reject the deletion
request with the error-tag value "data-missing", indicating that the
template is still in use.
To successfully delete a template, a client MUST first update the
target configuration nodes to remove the template identifier from
their "apply-templates" metadata attribute (as described in
Section 4.2.1), and then subsequently delete the template definition
itself.
4.6. Validity of Templates
The contents of the template alone is not always sufficient to
enforce the constraints of the data model. Some constraints may
depend on configuration outside of the templates to satisfy, e.g., a
list may contain a mandatory leaf node which is not defined in the
template but explicitly provided by the client. However, servers
SHOULD parse the template and enforce the constraints if it is
possible during the processing of template creation, e.g., servers
may validate type constraints for the leaf, including those defined
in the type's "range", "length", and "pattern" properties.
Implementations may also consider using mechanism defined in
[I-D.ietf-netmod-yang-anydata-validation] to validate anydata.
Watsen, et al. Expires 4 January 2027 [Page 14]
Internet-Draft template July 2026
That said, if a template is applied in the configuration data tree,
the results of the template configuration merging with configuration
explicitly provided by the client MUST always be valid, as defined in
Section 8.1 of [RFC7950].
5. Interaction with NMDA datastores
Some implementations may have predefined configuration templates for
the convenience of clients, which are present in <system> (if
implemented, see [I-D.ietf-netmod-system-config]). In addition,
clients can always define their own templates in <running>. However,
configuration template data defined by "ietf-config-template" YANG
data model should not be visible in <operational> until being
inherited by a node in the data tree.
If a node in the data tree applies a configuration template, the
configuration template does not expand in <running>. A read of
<running> returns what is sent by the client with the "apply-
templates" metadata attached to the specific node. A configuration
template which is inherited or overridden by the node instance MUST
be expanded in <intended>.
6. Interaction with Non-NMDA datastores
TBC
7. The "ietf-config-template" YANG Module
7.1. Data Model Overview
The following tree diagram [RFC8340] illustrates the "ietf-config-
template" module:
module: ietf-config-template
+--rw templates
+--rw template* [id]
+--rw id string
+--rw description? string
+--rw content? <anydata>
+--ro last-modified? yang:timestamp
Editor's Note: Should we use the RFC7952 metadata annotation for
the 'apply-templates' metadata here?
Editor's Note: the current definition of template configuration
uses anydata, but this may not be able to be validated at template
definition time because anydata is opaque.
Watsen, et al. Expires 4 January 2027 [Page 15]
Internet-Draft template July 2026
7.2. YANG Module
<CODE BEGINS> file "ietf-config-template@2026-07-03.yang"
module ietf-config-template {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-config-template";
prefix ct;
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data Types";
}
organization
"IETF NETMOD (Network Modeling) Working Group";
contact
"WG Web: https://datatracker.ietf.org/wg/netmod/
WG List: NETMOD <mailto:netmod@ietf.org>
Editor: Kent Watsen
<mailto:kent+ietf@watsen.net>
Editor: Qiufang Ma
<mailto:maqiufang1@huawei.com>
Editor: Deepak Rajaram
<mailto:deepak.rajaram@nokia.com>";
description
"This module defines a template list with a RPC to expand
the template.
Copyright (c) 2026 IETF Trust and the persons identified
as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with
or without modification, is permitted pursuant to, and
subject to the license terms contained in, the Revised
BSD License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC
itself for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
Watsen, et al. Expires 4 January 2027 [Page 16]
Internet-Draft template July 2026
are to be interpreted as described in BCP 14 (RFC 2119)
(RFC 8174) when, and only when, they appear in all
capitals, as shown here.";
revision 2026-07-03 {
description
"Initial revision.";
reference
"RFC XXXX: YANG Templates";
}
container templates {
description
"Specifies the template parameters.";
list template {
key id;
description
"The list of templates managed on this device.";
leaf id {
type string;
description
"The identifier of the template that uniquely identifies a
template.";
}
leaf description {
type string;
description
"A textual description of the template.";
}
anydata content {
description
"inline template content.";
}
leaf last-modified {
type yang:timestamp;
config false;
description
"Timestamp when the template is modified last time.";
}
}
}
}
<CODE ENDS>
Watsen, et al. Expires 4 January 2027 [Page 17]
Internet-Draft template July 2026
8. Operational Considerations
Implementations MAY restrict the applications of configuration
templates to some specific nodes in the YANG data tree. Restrictions
should be applied consistently across all client operations. Any
attempts to apply a template to a restricted node will be rejected.
Implementations are recommended to expose the list of configuration
nodes that do not support template application, any mechanisms to
achieve this are outside the scope of this document.
Configuration templates are designed to remain unexpanded in
<running>. This ensures storage efficiency and preserves the
client's control over <running>, i.e., reads of <running> returns the
client-submitted configuration with the "apply-templates" metadata
attached to target nodes. Any configuration template that is applied
in the data tree MUST be expanded in <intended>, which holds a merged
result of template expansion and configuration explicitly provided by
clients.
Implementations MAY differ in whether the configuration templates
themselves appear in <intended>, independent of whether the templates
are applied. Implementations MAY also support conditional
visibility, where templates appear in <intended> only when they are
applied by at least one node via the "apply-templates" annotation.
Regardless of the approach chosen, implementations MUST ensure the
behavior is consistent and deterministic, and SHOULD be documented to
allow clients to rely on predictable operational behaviors.
9. Security Considerations
TODO Security
10. IANA Considerations
10.1. The "IETF XML" Registry
This document registers the following URI in the "IETF XML Registry"
[RFC3688].
URI: urn:ietf:params:xml:ns:yang:ietf-config-template
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
10.2. The "YANG Module Names" Registry
This document registers the following YANG module in the "YANG Module
Names" registry [RFC6020].
Watsen, et al. Expires 4 January 2027 [Page 18]
Internet-Draft template July 2026
name: ietf-config-template
namespace: urn:ietf:params:xml:ns:yang:ietf-config-template
prefix: ct
maintained by IANA? N
reference: RFC XXXX
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/rfc/rfc3688>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/rfc/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/rfc/rfc6241>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/rfc/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/rfc/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/rfc/rfc8342>.
Watsen, et al. Expires 4 January 2027 [Page 19]
Internet-Draft template July 2026
[RFC9485] Bormann, C. and T. Bray, "I-Regexp: An Interoperable
Regular Expression Format", RFC 9485,
DOI 10.17487/RFC9485, October 2023,
<https://www.rfc-editor.org/rfc/rfc9485>.
11.2. Informative References
[I-D.ietf-netmod-system-config]
Ma, Q., Wu, Q., and C. Feng, "System-defined
Configuration", Work in Progress, Internet-Draft, draft-
ietf-netmod-system-config-20, 28 January 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
system-config-20>.
[I-D.ietf-netmod-yang-anydata-validation]
Elhassany, A. and T. Graf, "Validating anydata in YANG
Library context", Work in Progress, Internet-Draft, draft-
ietf-netmod-yang-anydata-validation-00, 2 December 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
yang-anydata-validation-00>.
[RFC7952] Lhotka, L., "Defining and Using Metadata with YANG",
RFC 7952, DOI 10.17487/RFC7952, August 2016,
<https://www.rfc-editor.org/rfc/rfc7952>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/rfc/rfc8340>.
[XSD-TYPES]
Biron, P. V., Permanente, K., and A. Malhotra, "XML Schema
Part 2: Datatypes Second Edition",
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
Appendix A. Requirement Implementation Status
Note to the RFC Editor: Please remove this section before
publication.
This appendix aims to track which of identified requirements have
been addressed in the current version, and, where applicable, how
they are fulfilled by the proposed mechanism.
These requirements are sourced from https://github.com/netmod-wg/
template-reqs/issues, specifically those that 1) have already been
discussed during interims and shown consensus, 2) present split
opinions and thus require further discussion, or 3) are new technical
requirements added by folks after interim discussion.
Watsen, et al. Expires 4 January 2027 [Page 20]
Internet-Draft template July 2026
+=====================+===========+===============================+
| Requirement | Fulfilled | Requirement Description |
+=====================+===========+===============================+
| R1: Allowed | Y | see Section 4.2 |
| Multiple templates | | |
| to be applied at a | | |
| single node | | |
+---------------------+-----------+-------------------------------+
| R2: Templates must | Y | see Section 4.1 |
| work with any YANG | | |
| module | | |
+---------------------+-----------+-------------------------------+
| R3: Templates must | N | Per discussion at IETF 125, |
| be validated when | | the consensus seems to be to |
| defined | | make a best effort to |
| | | validate the template at |
| | | definition time, and that the |
| | | current text is sufficient |
+---------------------+-----------+-------------------------------+
| R4: Local-config | Y | see Section 4.3 |
| overrides template- | | |
| config | | |
+---------------------+-----------+-------------------------------+
| R5: Living | Y | see Section 4.4 |
| template: modified | | |
| template data gets | | |
| expanded for all | | |
| consumers | | |
+---------------------+-----------+-------------------------------+
| R6: Support basic | N | Seems to add some complexity |
| programmatic | | |
| elements (loops, | | |
| conditions) in | | |
| templates | | |
+---------------------+-----------+-------------------------------+
| R7: Allow a server | Y | See Section 8 |
| to constrain which | | |
| nodes can be | | |
| templates consumer | | |
+---------------------+-----------+-------------------------------+
| R8: Configuration | Y | see Section 5 and Section 8 |
| with both expanded | | |
| and unexpanded | | |
| templates is able | | |
| to be returned | | |
+---------------------+-----------+-------------------------------+
| R9: <running> | Y | see Section 5, also stated |
| contains the | | explicitly in Section 8 |
Watsen, et al. Expires 4 January 2027 [Page 21]
Internet-Draft template July 2026
| unexpanded template | | |
+---------------------+-----------+-------------------------------+
| R10: <intended> | Y | see Section 5, also stated |
| contains the | | explicitly in Section 8 |
| expanded template | | |
+---------------------+-----------+-------------------------------+
| R11: Enables off- | Y | see Section 4.4 |
| box template | | |
| expansion of | | |
| <running> | | |
+---------------------+-----------+-------------------------------+
| R12: Support | Y | see Section 4.1.1 |
| limited regex in | | |
| templates | | |
+---------------------+-----------+-------------------------------+
| R13: Have a | Y | See Section 4.4 |
| precedence rule | | |
| when multiple | | |
| templates are | | |
| applied at a single | | |
| node | | |
+---------------------+-----------+-------------------------------+
| R14: The innermost | Y | See Section 4.4 |
| template takes | | |
| precedence when | | |
| templates are | | |
| applied at multiple | | |
| ancestor nodes | | |
+---------------------+-----------+-------------------------------+
| R15: Enable non- | N | have a dedicated section |
| NMDA servers to | | (Section 6) for this, but |
| return the expanded | | empty now |
| data | | |
+---------------------+-----------+-------------------------------+
| Not discussed: R16: | N | Seems to add some complexity, |
| exclude templates | | needs further discussion |
| applied at ancestor | | |
| nodes | | |
+---------------------+-----------+-------------------------------+
| Not discussed: R17: | N | Needs further discussion |
| Annotations to | | |
| determine which | | |
| template a node was | | |
| applied from | | |
+---------------------+-----------+-------------------------------+
Table 1
Watsen, et al. Expires 4 January 2027 [Page 22]
Internet-Draft template July 2026
Acknowledgments
The author would like to thank Lou Berger, Jason Sterne, Kent Watsen,
and Robert Wilton for comments and contributions made during interim
meetings.
The author would like to acknowledge the following drafts and
presenters for kick-starting discussions on Yang Templates:
* draft-ma-netmod-yang-config-template-00
* draft-rajaram-netmod-yang-cfg-template-framework-00
* draft-wills-netmod-yang-templates-00
* Jan Lindblad
Contributors
Robert Wills
Cisco
United Kingdom
Email: rowills@cisco.com
Qin Wu
Huawei
101 Software Avenue, Yuhua District
Jiangsu
210012
China
Email: bill.wu@huawei.com
Authors' Addresses
Kent Watsen
Watsen Networks
Email: kent+ietf@watsen.net
Qiufang Ma
Huawei
101 Software Avenue, Yuhua District
Jiangsu
210012
China
Email: maqiufang1@huawei.com
Watsen, et al. Expires 4 January 2027 [Page 23]
Internet-Draft template July 2026
Deepak Rajaram
Nokia
India
Email: deepak.rajaram@nokia.com
Watsen, et al. Expires 4 January 2027 [Page 24]