module yumaworks-templates { yang-version 1.1; namespace "http://yumaworks.com/ns/yumaworks-templates"; prefix "ytemp"; import ietf-netconf { prefix nc; } import yuma-types { prefix yt; } organization "YumaWorks, Inc."; contact "Support "; description "Configuration templates. These are used to pre-provision full or partial configuration subtrees that can be used like YANG defaults to provide missing values in actual configuration data. A configuration template con be specified for a container or a list, at any depth in the YANG data model. Configuration templates are only applied when a new instance of configuration data is created by a client with the operation, and only if the parameter is used. The template is expanded when the data is created in the candidate or running datastore. The SIL code and all validation is done post-expansion. Configuration data is applied from the template to the data target node in the following manner: * Only the child nodes of the data target node are compared for replacement. * If the corresponding child node already exists and not created by default, then the template child node is not copied. * If the template child node is defined within a YANG choice, then it will only be applied if no case is selected, or the same case is selected in the data target node. The /templates configuration subtree is used to configure named templates that can be used with the parameter added to the operation to apply named templates to configuration requests. The with-template leaf-list parameter is added to the edit-config operation. Multiple templates can be applied to the same edit, if the template matches the edit. A template can match the edit with 3 different tests. Only test (1) and (2) are mandatory. 1) with-template=, where matches an instance of /templates/template/name 2) the template identifies the same object as the new data node being created 3) if the template contains list keys then it will only be applied if the new data instance has the same key value, for each key leaf present in the template. A missing key leaf matches all instances of the data target. Copyright (c) 2017 YumaWorks, Inc. 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 BSD 3-Clause License http://opensource.org/licenses/BSD-3-Clause. "; revision 2017-02-20 { description "Initial version"; } augment /nc:edit-config/nc:input { description "Add the parameter to the edit-config operation"; leaf-list with-template { type yt:yang-identifier; // must match a template name ordered-by user; description "Identifies a configuration template to use for this edit operation. The 'target-path' parameter within the template will be matched to data in the configuration request. Templates will be checked in the order given, in case multiple templates for the same data node are provided."; } } container templates { list template { key name; leaf name { type yt:yang-identifier; description "Name of the template"; } leaf data-target { type string; mandatory true; description "Identifies the configuration data object that corresponds to this template. This must be a data node path expression. It is formatted like a RESTCONF path expression, except module names are not mandatory if they are unique. Only the data nodes are specified. No list keys can be provided for the template. Example: /ietf-interfaces:interfaces/interface "; } anydata data { mandatory true; description "Contains a single child element that corresponds to the data node identified by the data-target leaf. This subtree does not need to represent a complete data resource. It must contain well-formed YANG data node representations. YANG validation will only be attempted on real configuration data after the template data has been applied."; } } } }