| Internet-Draft | template | July 2026 |
| Watsen, et al. | Expires 4 January 2027 | [Page] |
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.¶
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.¶
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."¶
This Internet-Draft will expire on 4 January 2027.¶
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.¶
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.¶
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:¶
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:¶
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.¶
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.¶
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.¶
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.¶
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>.¶
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.¶
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.¶
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":¶
<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>
The YANG data model of configuration templates is defined in Section 7.¶
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":¶
<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>
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.¶
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:¶
<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>
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>
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>
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"/>
After this request, <running> is as shown in Figure 7:¶
<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 8 adds a new interface list entry, and leaves the applied templates unchanged:¶
<interfaces xmlns="urn:example:interface">
<interface>
<name>eth1</name>
</interface>
</interfaces>
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>
Finally, this request deletes all the templates, and leaves the list entries unchanged:¶
<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>
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>
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:¶
<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>
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>
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:¶
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>.¶
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.¶
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.¶
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].¶
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>.¶
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.¶
<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
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>¶
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.¶
TODO Security¶
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.
¶
This document registers the following YANG module in the "YANG Module Names" registry [RFC6020].¶
name: ietf-config-template
namespace: urn:ietf:params:xml:ns:yang:ietf-config-template
prefix: ct
maintained by IANA? N
reference: RFC XXXX
¶
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.¶
| Requirement | Fulfilled | Requirement Description |
|---|---|---|
| R1: Allowed Multiple templates to be applied at a single node | Y | see Section 4.2 |
| R2: Templates must work with any YANG module | Y | see Section 4.1 |
| R3: Templates must be validated when defined | N | Per discussion at IETF 125, the consensus seems to be to make a best effort to validate the template at definition time, and that the current text is sufficient |
| R4: Local-config overrides template-config | Y | see Section 4.3 |
| R5: Living template: modified template data gets expanded for all consumers | Y | see Section 4.4 |
| R6: Support basic programmatic elements (loops, conditions) in templates | N | Seems to add some complexity |
| R7: Allow a server to constrain which nodes can be templates consumer | Y | See Section 8 |
| R8: Configuration with both expanded and unexpanded templates is able to be returned | Y | see Section 5 and Section 8 |
| R9: <running> contains the unexpanded template | Y | see Section 5, also stated explicitly in Section 8 |
| R10: <intended> contains the expanded template | Y | see Section 5, also stated explicitly in Section 8 |
| R11: Enables off-box template expansion of <running> | Y | see Section 4.4 |
| R12: Support limited regex in templates | Y | see Section 4.1.1 |
| R13: Have a precedence rule when multiple templates are applied at a single node | Y | See Section 4.4 |
| R14: The innermost template takes precedence when templates are applied at multiple ancestor nodes | Y | See Section 4.4 |
| R15: Enable non-NMDA servers to return the expanded data | N | have a dedicated section (Section 6) for this, but empty now |
| Not discussed: R16: exclude templates applied at ancestor nodes | N | Seems to add some complexity, needs further discussion |
| Not discussed: R17: Annotations to determine which template a node was applied from | N | Needs further discussion |
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:¶