Hi Deepak, > 1) Are you assuming a default mode? (RFC 6243) > --No, this is not the default mode as per RFC 6243, it is just a leaf in the > module which has a default value.
Okay > 2) Does "that has a default” mean in the YANG module or configuration? > --In the yang module Glad I asked! > 3) What is an “instance”? (I think you mean “configuration”) > --Instance in the presentation means the functional entity to which the > defined template is applied. Let’s try to standardize some terminology. Technically, it is “configuration data” (RFC 6241) or a “data node” (RFC 7950). But I prefer we come up with something more intuitive (use case specific). I’ve been using the term “template consumer” for this, but open to anything others prefer that makes sense. I do not think that “instance” or “template instance” is good because it suggests a 1-1 correspondence (i.e., a template consumer can reference to at most one template), whereas I think that a template consumer can reference a list of templates (see https://github.com/netmod-wg/template-reqs/issues/1 > A example which could provide more explanation is below > > --------Template schema ------------- > In this snippet we define the schema of a template for interfaces/interface, > which includes the leaf "enabled" which has a default value as true and a > leaf "type" which has a mandatory value. > > container templates{ > list templates{ > key "template-name"; > leaf template-name { > type string; > description "The name of the template."; > } > container interfaces { > list interface { > key "name"; > description "List of network interfaces."; > leaf name { > type string; > description "The name of the interface."; > mandatory true; > } > leaf type { > type identityref { > base "interface-type"; > } > description "The type of the interface."; > mandatory true; // The interface type is mandatory > } > leaf enabled { > type boolean; > default "true"; // The default state is enabled > description > "The enabled state of the interface. True means the interface > is enabled, false means it is disabled."; > } Thank you for posting this snippet of YANG! This YANG snippet illustrates what might be called a “data model specific template”, which I do not support (as a contributor, of course) for a following reasons (see also https://github.com/netmod-wg/template-reqs/issues/3): 1) it potentially doubles the size of the YANG (depending on how much is templatized) 2) it assumes a specific data-model (/interfaces in this example) whereas it may be desired to just templatize /interfaces/interface. 3) it requires additional YANG modules to support, potentially leading to delay and/or inconsistencies. Is the allure to having data model specific templates to allow the template to be validated when defined, as opposed to when used (see https://github.com/netmod-wg/template-reqs/issues/4)? FWIW, here’s a stripped-down YANG snippet for a data-model *independent* module: container templates{ list templates { key "name"; leaf name { type string; } anydata content {} } } The “content” node can contain any data tree, even those having more than one top-level node. > --------Template configuration ------------- > <rpc message-id="102" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > <edit-config> > <target> > <running/> > </target> > <config> > <templates> > <template> > <template-name>sample-template</template-name> > <interfaces > xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"> > <interface> > > <name>GigabitEthernet0/0/0</name> > <type > xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">ianaift:ethernetCsmacd</type> > <!-- Mandatory leaf --> > > <enabled>false</enabled><!—default leaf, but assuming this value is set to > the non-default value(false).--> > </interface> > </interfaces> > </template> > </templates> > </config> > </edit-config> > </rpc> > > When this template is applied to the interface model, will the leaf "enabled" > not conflict with what is defined in the template, because the leaf "enabled" > has a default value as "true" as compared to what has been configured in the > template(false). I don’t understand the problem. Partially because IDK the contents of <running> are assumed to be. For future examples, just providing <running> containing both the /interfaces and the /templates trees would be great. In any case, I see no conflict with a template providing an “enabled” leaf value of either “true” or “false”. Both are valid input values (same as for any YANG ‘leaf’ having a default). To your point, explicitly setting the value “true” is potentially unnecessary, since it is the same value as the default value, but sometimes clients like to explicitly set the default value, perhaps for readability purposes, or to ensure no impact to the production environment in case the YANG-defined default changes (e.g., after a software upgrade). Kent // contributor
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
