Extensions
abstract
Summary
Name | abstract |
Module | yuma-ncx |
Version | 2015-10-16 |
Used with object definitions to indicate that they do not represent CLI or NETCONF configuration database data instances. Instead, the node is simply an object identifier, an 'error-info' extension, or some other abstract data structure. |
Details
Version | 2015-10-16 |
File | yuma-ncx |
Line | 439 |
Source | yuma-ncx.yang line 439 |
abstract
Summary
Name | abstract |
Module | ietf-complex-types |
Version | 2011-03-15 |
Makes the complex-type abstract. |
Details
Argument | status |
YIN Element | 0 |
Version | 2011-03-15 |
File | ietf-complex-types |
Line | 53 |
Reference | Section 2.6, abstract Extension Statement |
Source | ietf-complex-types.yang line 53 |
abstract
Summary
Name | abstract |
Module | ietf-complex-types |
Version | 2010-12-10 |
Makes the complex-type abstract. |
Details
Argument | status |
YIN Element | 0 |
Version | 2010-12-10 |
File | ietf-complex-types |
Line | 60 |
Reference | section 2.6., abstract extension statement |
Source | ietf-complex-types.yang line 60 |
alias
Summary
Name | alias |
Module | ietf-yang-smiv2 |
Version | 2012-06-22 |
The alias statement introduces an SMIv2 descriptor. The body of the alias statement is expected to contain an oid statement that provides the numeric OID associated with the descriptor. |
Details
Argument | descriptor |
YIN Element | 0 |
Version | 2012-06-22 |
File | ietf-yang-smiv2 |
Line | 112 |
Reference | RFC 2578: Structure of Management Information Version 2 (SMIv2) |
Source | ietf-yang-smiv2.yang line 112 |
also-augments
Summary
Name | also-augments |
Module | ietf-commonaugment |
Version | 2017-03-04 |
The argument is a string that identifies a node in the schema tree and is the same argument that is defined for the YANG argument statement |
Details
Argument | target-node |
YIN Element | 0 |
Version | 2017-03-04 |
File | ietf-commonaugment |
Line | 44 |
Source | ietf-commonaugment.yang line 44 |
alt-name
Summary
Name | alt-name |
Module | yumaworks-extensions |
Version | 2020-03-31 |
Used within a data node definition to specify an alternate name for the node. The --alt-names parameter must be enabled for these names to be used. The argument is the alternate name to use. It must be a valid YANG identifier. |
Details
Argument | name |
YIN Element | 0 |
Version | 2020-03-31 |
File | yumaworks-extensions |
Line | 95 |
Source | yumaworks-extensions.yang line 95 |
annotation
Summary
Name | annotation |
Module | ietf-yang-metadata |
Version | 2015-09-17 |
This extension allows for defining metadata annotations in YANG modules. The 'md:annotation' statement can appear only at the top level of a YANG module. The argument of the 'md:annotation' statement defines the name of the annotation. Syntactically it is a YANG identifier as defined in RFC 6020bis, sec. 6.2. An annotation defined with this extension statement inherits the namespace and other context from the YANG module in which it is defined. Data type of the annotation value is specified in the same way as for a leaf data node using the 'type' statement. Semantics of the annotation and other documentation can be specified using the following standard YANG substatements (all are optional): 'description', 'if-feature', 'reference', 'status', and 'units'. A server announces support for a particular annotation by including the module in which the annotation is defined among the advertised YANG modules (e.g., in NETCONF hello message or yang-library). The annotation then can be attached to any instance of data node defined in any YANG module that is advertised by the server. XML and JSON encoding of annotations is defined in RFC XXXX. |
Details
Argument | name |
YIN Element | 0 |
Version | 2015-09-17 |
File | ietf-yang-metadata |
Line | 56 |
Source | ietf-yang-metadata.yang line 56 |
annotation
Summary
Name | annotation |
Module | ietf-yang-metadata |
Version | 2016-08-05 |
This extension allows for defining metadata annotations in YANG modules. The 'md:annotation' statement can appear only at the top level of a YANG module or submodule, i.e., it becomes a new alternative in the ABNF production rule for 'body-stmts' (Section 14 in RFC 7950). The argument of the 'md:annotation' statement defines the name of the annotation. Syntactically, it is a YANG identifier as defined in Section 6.2 of RFC 7950. An annotation defined with this 'extension' statement inherits the namespace and other context from the YANG module in which it is defined. The data type of the annotation value is specified in the same way as for a leaf data node using the 'type' statement. The semantics of the annotation and other documentation can be specified using the following standard YANG substatements (all are optional): 'description', 'if-feature', 'reference', 'status', and 'units'. A server announces support for a particular annotation by including the module in which the annotation is defined among the advertised YANG modules, e.g., in a NETCONF <hello> message or in the YANG library (RFC 7950). The annotation can then be attached to any instance of a data node defined in any YANG module that is advertised by the server. XML encoding and JSON encoding of annotations are defined in RFC 7952. |
Details
Argument | name |
YIN Element | 0 |
Version | 2016-08-05 |
File | ietf-yang-metadata |
Line | 49 |
Source | ietf-yang-metadata.yang line 49 |
augment-structure
Summary
Name | augment-structure |
Module | ietf-yang-structure-ext |
Version | 2020-06-17 |
This extension is used to specify an augmentation to a YANG data structure defined with the 'structure' statement. It is intended to describe hierarchical data independent of protocol context or specific message encoding format. This statement has almost the same structure as the 'augment-stmt'. Data definition statements within this statement specify the semantics and generic syntax for the additional data to be added to the specific YANG data structure, identified by the 'path' argument. The mandatory 'path' parameter value identifies the YANG conceptual data node that is being augmented and is represented as an absolute-schema-nodeid string, where the first node in the absolute-schema-nodeid string identifies the YANG data structure to augment, and the rest of the nodes in the string identifies the node within the YANG structure to augment. This extension is only valid as a top-level statement, i.e., given as a substatement to 'module' or 'submodule'. The substatements of this extension MUST follow the ABNF rules below, where the rules are defined in RFC 7950: [status-stmt] [description-stmt] [reference-stmt] 1*(data-def-stmt / case-stmt) The module name and namespace value for the YANG module using the extension statement are assigned to instance document data conforming to the data definition statements within this extension. The XPath document element is the augmented extension statement itself, such that the child nodes of the document element are represented by the data-def-stmt substatements within the augmented 'structure' statement. The context node of the 'augment-structure' statement is derived in the same way as the 'augment' statement, as defined in Section 6.4.1 of [RFC7950]. This conceptual node is considered the context node for the following YANG statements: - must-stmt - when-stmt - path-stmt - min-elements-stmt - max-elements-stmt - mandatory-stmt - unique-stmt - ordered-by - instance-identifier data type The following data-def-stmt substatements are constrained when used within an 'augment-structure' extension statement. - The list-stmt is not required to have a key-stmt defined. - The config-stmt is ignored if present. Example: module foo { import ietf-yang-structure-ext { prefix sx; } sx:structure foo-data { container foo-con { } } } module bar { import ietf-yang-structure-ext { prefix sx; } import foo { prefix foo; } sx:augment-structure /foo:foo-data/foo:foo-con { leaf add-leaf1 { type int32; } leaf add-leaf2 { type string; } } } |
Details
Argument | path |
YIN Element | 1 |
Version | 2020-06-17 |
File | ietf-yang-structure-ext |
Line | 119 |
Source | ietf-yang-structure-ext.yang line 119 |
augment-yang-data
Summary
Name | augment-yang-data |
Module | yang-data-ext |
Version | 2017-07-03 |
This extension is used to specify an augmentation to conceptual data defined with the 'yang-data' statement. It is intended to describe hierarchical data independent of protocol context or specific message encoding format. This statement has almost the same structure as the 'augment-stmt'. Data definition statements within this statement specify the semantics and generic syntax for the additional data to be added to the specific YANG data template, identified by the 'path' argument. Note that this extension does not define a media-type. A specification using this extension MUST specify the message encoding rules, including the content media type. The mandatory 'path' parameter value identifies the YANG conceptual data node that is being augmented, represented as an absolute-schema-nodeid string. This extension is ignored unless it appears as a top-level statement. The sub-statements of this extension MUST follow the 'data-def-stmt' rule in the YANG ABNF. The module name and namespace value for the YANG module using the extension statement is assigned to instance document data conforming to the data definition statements within this extension. The XPath document root is the augmented extension statement itself, such that the child nodes of the document root are represented by the data-def-stmt sub-statements within the augmented yang-data statement. The context node of the augment-yang-data statement is derived in the same way as the 'augment' statement, as defined in section 6.4.1 of [RFC7950]. This conceptual node is considered the context node for the following YANG statements: - must-stmt - when-stmt - path-stmt - min-elements-stmt - max-elements-stmt - mandatory-stmt - unique-stmt - ordered-by - instance-identifier data type The following data-def-stmt sub-statements are constrained when used within a augment-yang-data extension statement. - The list-stmt is not required to have a key-stmt defined. - The if-feature-stmt is ignored if present. - The config-stmt is ignored if present. - The available identity values for any 'identityref' leaf or leaf-list nodes is limited to the module containing this extension statement, and the modules imported into that module. Example: foo.yang { import ietf-restconf { prefix rc; } rc:yang-data foo-data { container foo-con { } } } bar.yang { import yang-data-ext { prefix yd; } import foo { prefix foo; } yd:augment-yang-data /foo:foo-con { leaf add-leaf1 { type int32; } leaf add-leaf2 { type string; } } } |
Details
Argument | path |
YIN Element | 1 |
Version | 2017-07-03 |
File | yang-data-ext |
Line | 36 |
Source | yang-data-ext.yang line 36 |
catalog-organization
Summary
Name | catalog-organization |
Module | openconfig-extensions |
Version | 2020-06-16 |
This extension specifies the organization name that should be used within the module catalogue on the device for the specified YANG module. It stores a pithy string where the YANG organization statement may contain more details. |
Details
Argument | org |
YIN Element | 0 |
Version | 2020-06-16 |
File | openconfig-extensions |
Line | 177 |
Source | openconfig-extensions.yang line 177 |
cli
Summary
Name | cli |
Module | yuma-ncx |
Version | 2015-10-16 |
Used within a container definition to indicate it is only used as a conceptual container for a set of CLI parameters. A top-level container containing this extension will not be included in any NETCONF configuration databases. |
Details
Version | 2015-10-16 |
File | yuma-ncx |
Line | 448 |
Source | yuma-ncx.yang line 448 |
cli-text-block
Summary
Name | cli-text-block |
Module | yumaworks-extensions |
Version | 2020-03-31 |
If this extension is present in an empty container or list, it will be treated in unit-test parsing as a container or list of ordered text commands, 1 per line. Line extension is needed to wrap a command into many lines. Example YANG: container setup { ywx:cli-text-block; } Example test script or conf file usage: setup { run test1-script get-config source=running lock target=candidate } |
Details
Version | 2020-03-31 |
File | yumaworks-extensions |
Line | 124 |
Source | yumaworks-extensions.yang line 124 |
complex-type
Summary
Name | complex-type |
Module | ietf-complex-types |
Version | 2011-03-15 |
Defines a complex-type. |
Details
Argument | type-identifier |
YIN Element | 1 |
Version | 2011-03-15 |
File | ietf-complex-types |
Line | 38 |
Reference | Section 2.2, complex-type Extension Statement |
Source | ietf-complex-types.yang line 38 |
complex-type
Summary
Name | complex-type |
Module | ietf-complex-types |
Version | 2010-12-10 |
Defines a complex-type. |
Details
Argument | type-identifier |
YIN Element | 1 |
Version | 2010-12-10 |
File | ietf-complex-types |
Line | 44 |
Reference | section 2.2., complex-type extension statement |
Source | ietf-complex-types.yang line 44 |
datapath
Summary
Name | datapath |
Module | yumaworks-extensions |
Version | 2020-03-31 |
Used within a container or anyxml definition to indicate that the object path for the data node should be sent in the value as an attribute. The SIL-SA parser will use the datapath attribute to select the object template to use for parsing, instead of generic anyxml. anyxml newval { ywx:datapath; } anyxml curval { ywx:datapath; } If /foo/bar/leaf2 is edited, the <edit> message will be generated with the datapath attribute from the yumaworks-attrs module. <newval ywattrs:datapath='/foo/bar/leaf2'>42</newval> <curval ywattrs:datapath='/foo/bar/leaf2'>67</curval> |
Details
Version | 2020-03-31 |
File | yumaworks-extensions |
Line | 172 |
Source | yumaworks-extensions.yang line 172 |
default-deny-all
Summary
Name | default-deny-all |
Module | yuma-nacm |
Version | 2012-10-05 |
Copy of IETF version of 'very-secure' extension. |
Details
Version | 2012-10-05 |
File | yuma-nacm |
Line | 136 |
Reference | RFC 6536 |
Source | yuma-nacm.yang line 136 |
default-deny-all
Summary
Name | default-deny-all |
Module | ietf-netconf-acm |
Version | 2012-02-22 |
Used to indicate that the data model node controls a very sensitive security system parameter. If present, and the NACM module is enabled (i.e., /nacm/enable-nacm object equals 'true'), the NETCONF server will only allow the designated 'recovery session' to have read, write, or execute access to the node. An explicit access control rule is required for all other users. The 'default-deny-all' extension MAY appear within a data definition statement, 'rpc' statement, or 'notification' statement. It is ignored otherwise. |
Details
Version | 2012-02-22 |
File | ietf-netconf-acm |
Line | 73 |
Source | ietf-netconf-acm.yang line 73 |
default-deny-all
Summary
Name | default-deny-all |
Module | ietf-netconf-acm |
Version | 2018-02-14 |
Used to indicate that the data model node controls a very sensitive security system parameter. If present, the NETCONF server will only allow the designated 'recovery session' to have read, write, or execute access to the node. An explicit access control rule is required for all other users. If the NACM module is used, then it must be enabled (i.e., /nacm/enable-nacm object equals 'true'), or this extension is ignored. The 'default-deny-all' extension MAY appear within a data definition statement, 'rpc' statement, or 'notification' statement. It is ignored otherwise. |
Details
Version | 2018-02-14 |
File | ietf-netconf-acm |
Line | 78 |
Source | ietf-netconf-acm.yang line 78 |
default-deny-write
Summary
Name | default-deny-write |
Module | yuma-nacm |
Version | 2012-10-05 |
Copy of IETF version of 'secure' extension. |
Details
Version | 2012-10-05 |
File | yuma-nacm |
Line | 130 |
Reference | RFC 6536 |
Source | yuma-nacm.yang line 130 |
default-deny-write
Summary
Name | default-deny-write |
Module | ietf-netconf-acm |
Version | 2012-02-22 |
Used to indicate that the data model node represents a sensitive security system parameter. If present, and the NACM module is enabled (i.e., /nacm/enable-nacm object equals 'true'), the NETCONF server will only allow the designated 'recovery session' to have write access to the node. An explicit access control rule is required for all other users. The 'default-deny-write' extension MAY appear within a data definition statement. It is ignored otherwise. |
Details
Version | 2012-02-22 |
File | ietf-netconf-acm |
Line | 58 |
Source | ietf-netconf-acm.yang line 58 |
default-deny-write
Summary
Name | default-deny-write |
Module | ietf-netconf-acm |
Version | 2018-02-14 |
Used to indicate that the data model node represents a sensitive security system parameter. If present, the NETCONF server will only allow the designated 'recovery session' to have write access to the node. An explicit access control rule is required for all other users. If the NACM module is used, then it must be enabled (i.e., /nacm/enable-nacm object equals 'true'), or this extension is ignored. The 'default-deny-write' extension MAY appear within a data definition statement. It is ignored otherwise. |
Details
Version | 2018-02-14 |
File | ietf-netconf-acm |
Line | 61 |
Source | ietf-netconf-acm.yang line 61 |
default-parm
Summary
Name | default-parm |
Module | yuma-ncx |
Version | 2015-10-16 |
Used within a CLI container or rpc definition to specify a leaf parameter within the CLI container or rpc input section, that is used as the default if no parameter name is entered. These values must not begin with a dash (-) or double dash (--) sequence or they will be mistaken for CLI parameter names. This option is somewhat risky because any unrecognized parameter without any prefix (- or --) will be tried as the default parameter type, instead of catching the unknown parameter error. It can also be useful though, for assigning file name parameters through shell expansion, or if there is only one parameter. |
Details
Argument | parm |
YIN Element | 1 |
Version | 2015-10-16 |
File | yuma-ncx |
Line | 456 |
Source | yuma-ncx.yang line 456 |
default-parm-equals-ok
Summary
Name | default-parm-equals-ok |
Module | yuma-ncx |
Version | 2015-10-16 |
Used within a CLI container or rpc definition to specify a leaf parameter within the CLI container or rpc input section, that is used as the default if no parameter name is entered. This can be used in addition to ncx:default-parm to allow an equals sign '=' in the default parm string value. This option is quite risky because any unrecognized parameter without any prefix (- or --) will be tried as the default parameter type, instead of catching the unknown parameter error. This includes strings containing an equals sign, so an unknown parameter error will never be generated. rpc foo { input { ncx:default-parm a; ncx:default-parm-equals-ok; leaf a { type string; } leaf b { type int32; } } } yangcli> foo bogus-parm=fred This will interpreted as if parameter 'a' were entered: yangcli> foo a='bogus-parm=fred' |
Details
Version | 2015-10-16 |
File | yuma-ncx |
Line | 478 |
Source | yuma-ncx.yang line 478 |
defval
Summary
Name | defval |
Module | ietf-yang-smiv2 |
Version | 2012-06-22 |
The defval statement takes as an argument a default value defined by an SMIv2 DEFVAL clause. Note that the value is in the SMIv2 value space defined by the SMIv2 syntax of the corresponding object and not in the YANG value space defined by the corresponding YANG data type. |
Details
Argument | value |
YIN Element | 0 |
Version | 2012-06-22 |
File | ietf-yang-smiv2 |
Line | 90 |
Reference | RFC 2578: Structure of Management Information Version 2 (SMIv2) |
Source | ietf-yang-smiv2.yang line 90 |
derivedUnits
Summary
Name | derivedUnits |
Module | ieee1906-dot1-si-units |
Version | 2020-07-07 |
This extension allows the use of an SI (or even a non SI) unit for a specific physic concept. This helps a NETCONF server to accept different scales or magnitude orders for the same meaning. For example, length can be expressed into 'astronomical-units' or 'picometers'. As long as the NETCONF server can make the translation between the units this should not raise an <rpc-error>. If a server fails to perform this translation either: 1. Because it does not support the corresponding mapping 2. Because the unit provided is wrong (a client specifying a distance in kg) The NETCONF node MUST return an <rpc-error> with a <bad-attribute> element specifying that it could not perform the conversion. YANG nodes allowing this extension should be leaf and list-leaf only. When using this extension into the YANG leaf or list-leaf definition: 1. Use the unit names only, not the symbols. 2. Do not add the prefixes as they should be implicitly understood by the NETCONF server. 3. Do not add neper, bel, and decibel unless you want to be explicit. For example, a loss is unitless and unit should be 'one'. You do not have to use this extension to accept 'dB' as it makes sense for a loss. However, dBm must be defined in this extension to provide a ratio over 1mW. 3. Do not use this extension if the leaf has no unit substatement defined. This extension should not be part of a container or a list for the reason there can be inconsistency between the leaves and the container. This extension helps the user only to use different SI and non SI units for the same YANG type. This extension does not provide conversion between the units and the NETCONF server should not rely on this extension to perform validations. This extension should be used with an annotation, allowing the client to insert an XML attribute specifying the unit attached to the value it provides. If the attribute is not specified, then the fundamental unit expressed in the unit substatement of the containing YANG leaf must be used. When the client uses an XML attribute requesting a change of units, the client should use names but may use symbols. The client should use SI prefix names but may use SI prefix symbols instead (the charset for greek letters may not be supported on the server). |
Details
Argument | name |
YIN Element | 0 |
Version | 2020-07-07 |
File | ieee1906-dot1-si-units |
Line | 142 |
Source | ieee1906-dot1-si-units.yang line 142 |
display-hint
Summary
Name | display-hint |
Module | ietf-yang-smiv2 |
Version | 2012-06-22 |
The display-hint statement takes as an argument the DISPLAY-HINT assigned to an SMIv2 textual convention. |
Details
Argument | format |
YIN Element | 0 |
Version | 2012-06-22 |
File | ietf-yang-smiv2 |
Line | 68 |
Reference | RFC 2579: Textual Conventions for SMIv2 |
Source | ietf-yang-smiv2.yang line 68 |
equation
Summary
Name | equation |
Module | ieee1906-dot1-math |
Version | 2020-07-07 |
An equation is a list of expressions. The equation is considered well known and easy to obtain a consensus to within the scientific community. It is outside the scope of this YANG model to describe what the equation does. Instead, this YANG model refers to well-known or consensual equations. For example, the mass flow rate equation is well known and has the following accepted expressions: mdot = rho . Vdot = rho . V . A = jm . A Note that this naming uses symbols. Symbols are also defined and are only hints for a human user. Convention should use the name attached to the symbol to get a meaningful notion of what is expressed. An equation can be named for functional programming purposes. An equation may have a value. In the example of the mass flow rate equation, mdot is the value. The value is a function:variable. |
Details
Argument | equation-name |
YIN Element | 0 |
Version | 2020-07-07 |
File | ieee1906-dot1-math |
Line | 64 |
Source | ieee1906-dot1-math.yang line 64 |
errmsg
Summary
Name | errmsg |
Module | yumaworks-extensions |
Version | 2020-03-31 |
Used within a data node statement to define a custom error-message filed within an 'rpc-error' or 'error' structure for some or all error conditions. The string format is restricted to plain text with the exception of the 2 character sequence '%s'. This special sequence will be replaced in the dynamic error message generation if an errmsg-parm statement is found to match the escape sequence. If this extension statement has no sub-statements, then it matches all errors for the object. If 'errmsg-tag' sub-statements are found, then this entry will match only those error-tag values. If 'errmsg-apptag' sub-statements are found, then this entry will match only those error-app-tag values. The 'basestr' argument must be formatted string. If any parameters are specified, then the corresponding 'errmsg-parm' extension statements must be encoded within this errmsg statement. Multiple errmsg statements can be present in the same data node statement. They will be processed in order and the first matching statement will be used to generate the error-message value. Example: leaf my-network-id { type int32; ywx:errmsg 'Not a valid network ID for interface %s' { ywx:errmsg-parm '../../if:name'; ywx:errmsg-apptag 'network-error'; } } |
Details
Argument | basestr |
YIN Element | 0 |
Version | 2020-03-31 |
File | yumaworks-extensions |
Line | 278 |
Source | yumaworks-extensions.yang line 278 |
errmsg-apptag
Summary
Name | errmsg-apptag |
Module | yumaworks-extensions |
Version | 2020-03-31 |
Used within an errmsg statement to define an error-app-tag value that will filter this errmsg. Multiple errmsg-tag and/or errmsg-apptag values form a conceptual OR expression. The 'apptagstr' argument must be the error-app-tag value that will be matched. |
Details
Argument | apptagstr |
YIN Element | 0 |
Version | 2020-03-31 |
File | yumaworks-extensions |
Line | 347 |
Source | yumaworks-extensions.yang line 347 |
errmsg-lang
Summary
Name | errmsg-lang |
Module | yumaworks-extensions |
Version | 2020-03-31 |
Used within an errmsg statement to define the language code value that will filter this errmsg. Only one errmsg-lang statement may appear within an errmsg statement. The 'langstr' value will be compared to the 'errmsg-lang' CLI variable setting. If the strings are the same, the entry is used. If this statement is not present, then the errmsg entry will be used regardless of the 'errmsg-lang' CLI variable setting. The 'langstr' argument must be the language code value that will be matched. |
Details
Argument | langstr |
YIN Element | 0 |
Version | 2020-03-31 |
File | yumaworks-extensions |
Line | 360 |
Source | yumaworks-extensions.yang line 360 |
errmsg-parm
Summary
Name | errmsg-parm |
Module | yumaworks-extensions |
Version | 2020-03-31 |
Used within an errmsg statement to define a parameter for expansion within the errmsg basestr. There should be the correct number of expected parameters for the corresponding 'basestr' format string. The 'parmstr' argument must be an XPath path expression. The context node will be the data node containing the errmsg statement. |
Details
Argument | parmstr |
YIN Element | 0 |
Version | 2020-03-31 |
File | yumaworks-extensions |
Line | 320 |
Source | yumaworks-extensions.yang line 320 |
errmsg-tag
Summary
Name | errmsg-tag |
Module | yumaworks-extensions |
Version | 2020-03-31 |
Used within an errmsg statement to define an error-tag value that will filter this errmsg. Multiple errmsg-tag and/or errmsg-apptag values form a conceptual OR expression. The 'tagstr' argument must be the error-tag value that will be matched. |
Details
Argument | tagstr |
YIN Element | 0 |
Version | 2020-03-31 |
File | yumaworks-extensions |
Line | 334 |
Source | yumaworks-extensions.yang line 334 |
exclusive-rpc
Summary
Name | exclusive-rpc |
Module | yumaworks-extensions |
Version | 2020-03-31 |
Used within an rpc definition statement to indicate that the RPC is not allowed to be called concurrently by different sessions. The server will return an in-use error if another session is currently invoking the RPC operation and this extension is present in the rpc-stmt. |
Details
Version | 2020-03-31 |
File | yumaworks-extensions |
Line | 162 |
Source | yumaworks-extensions.yang line 162 |
expression
Summary
Name | expression |
Module | ieee1906-dot1-math |
Version | 2020-07-07 |
An expression is part of an equation. Two expressions in an equation are equivalent. An expression is a list of unknown or variables linked by operations. The expression is considered well known and easy to obtain a consensus to within the scientific community. It is outside of the scope of this YANG model to describe the relationship between the unknown. Instead, the expression provides a list of unknowns or variables. |
Details
Version | 2020-07-07 |
File | ieee1906-dot1-math |
Line | 87 |
Source | ieee1906-dot1-math.yang line 87 |
extends
Summary
Name | extends |
Module | ietf-complex-types |
Version | 2011-03-15 |
Defines the base type of a complex-type. |
Details
Argument | base-type-identifier |
YIN Element | 1 |
Version | 2011-03-15 |
File | ietf-complex-types |
Line | 46 |
Reference | Section 2.5, extends Extension Statement |
Source | ietf-complex-types.yang line 46 |
extends
Summary
Name | extends |
Module | ietf-complex-types |
Version | 2010-12-10 |
Defines the base type of a complex-type. |
Details
Argument | base-type-identifier |
YIN Element | 1 |
Version | 2010-12-10 |
File | ietf-complex-types |
Line | 52 |
Reference | section 2.5., extends extension statement |
Source | ietf-complex-types.yang line 52 |
get-filter-element-attributes
Summary
Name | get-filter-element-attributes |
Module | yuma-netconf |
Version | 2015-04-30 |
If this extension is present within the an 'anyxml' statement named 'filter', which must be conceptually defined within the RPC input section for the 'get' and 'get-config' RPC operations, then the following unqualified XML attribute is supported within the 'filter' element, within a 'get' or 'get-config' protocol operation: type : optional attribute with allowed value strings 'subtree' and 'xpath'. If missing, the default value is 'subtree'. If the 'xpath' feature is supported, then the following unqualified XML attribute is also supported: select: optional attribute containing a string representing an XPath expression. The 'type' attribute must be equal to 'xpath' if this attribute is present. |
Details
Version | 2015-04-30 |
File | yuma-netconf |
Line | 108 |
Source | yuma-netconf.yang line 108 |
get-filter-element-attributes
Summary
Name | get-filter-element-attributes |
Module | ietf-netconf |
Version | 2011-06-01 |
If this extension is present within an 'anyxml' statement named 'filter', which must be conceptually defined within the RPC input section for the <get> and <get-config> protocol operations, then the following unqualified XML attribute is supported within the <filter> element, within a <get> or <get-config> protocol operation: type : optional attribute with allowed value strings 'subtree' and 'xpath'. If missing, the default value is 'subtree'. If the 'xpath' feature is supported, then the following unqualified XML attribute is also supported: select: optional attribute containing a string representing an XPath expression. The 'type' attribute must be equal to 'xpath' if this attribute is present. |
Details
Version | 2011-06-01 |
File | ietf-netconf |
Line | 56 |
Source | ietf-netconf.yang line 56 |
help
Summary
Name | help |
Module | yumaworks-extensions |
Version | 2020-03-31 |
Used within a rpc or data definition statement to provide a short help text string for CLI and other applications to use in addition to the description statement. The 'helptext' argument is the help text string, which should be 60 characters or less in length. |
Details
Argument | helptext |
YIN Element | 1 |
Version | 2020-03-31 |
File | yumaworks-extensions |
Line | 148 |
Source | yumaworks-extensions.yang line 148 |
hidden
Summary
Name | hidden |
Module | yuma-ncx |
Version | 2015-10-16 |
Used to prevent publication of a YANG data object. Will be ignored for typedefs and other constructs. If present, that node and any sub-nodes will be ignored when generating HTML documentation or cYANG output. The yangdump -f=copy mode will not be affected by this extension. |
Details
Version | 2015-10-16 |
File | yuma-ncx |
Line | 512 |
Source | yuma-ncx.yang line 512 |
implied
Summary
Name | implied |
Module | ietf-yang-smiv2 |
Version | 2012-06-22 |
If an SMIv2 INDEX object is preceded by the IMPLIED keyword, then the implied statement is present in the YANG module and takes as an argument the name of the IMPLIED index object. |
Details
Argument | index |
YIN Element | 0 |
Version | 2012-06-22 |
File | ietf-yang-smiv2 |
Line | 102 |
Reference | RFC 2578: Structure of Management Information Version 2 (SMIv2) |
Source | ietf-yang-smiv2.yang line 102 |
instance
Summary
Name | instance |
Module | ietf-complex-types |
Version | 2011-03-15 |
Declares an instance of the given complex type. |
Details
Argument | ct-instance-identifier |
YIN Element | 1 |
Version | 2011-03-15 |
File | ietf-complex-types |
Line | 59 |
Reference | Section 2.3, instance Extension Statement |
Source | ietf-complex-types.yang line 59 |
instance
Summary
Name | instance |
Module | ietf-complex-types |
Version | 2010-12-10 |
Declares an instance of the given complex type. |
Details
Argument | ct-instance-identifier |
YIN Element | 1 |
Version | 2010-12-10 |
File | ietf-complex-types |
Line | 66 |
Reference | section 2.3., instance extension statement |
Source | ietf-complex-types.yang line 66 |
instance-list
Summary
Name | instance-list |
Module | ietf-complex-types |
Version | 2011-03-15 |
Declares a list of instances of the given complex type |
Details
Argument | ct-instance-identifier |
YIN Element | 1 |
Version | 2011-03-15 |
File | ietf-complex-types |
Line | 68 |
Reference | Section 2.4, instance-list Extension Statement |
Source | ietf-complex-types.yang line 68 |
instance-list
Summary
Name | instance-list |
Module | ietf-complex-types |
Version | 2010-12-10 |
Declares a list of instances of the given complex type |
Details
Argument | ct-instance-identifier |
YIN Element | 1 |
Version | 2010-12-10 |
File | ietf-complex-types |
Line | 75 |
Reference | section 2.4., instance-list extension statement |
Source | ietf-complex-types.yang line 75 |
instance-type
Summary
Name | instance-type |
Module | ietf-complex-types |
Version | 2011-03-15 |
Tells to which type instance the instance identifier refers. |
Details
Argument | target-type-identifier |
YIN Element | 1 |
Version | 2011-03-15 |
File | ietf-complex-types |
Line | 77 |
Reference | Section 3.2, instance-type Extension Statement |
Source | ietf-complex-types.yang line 77 |
instance-type
Summary
Name | instance-type |
Module | ietf-complex-types |
Version | 2010-12-10 |
Tells to which type instance the instance identifier refers to. |
Details
Argument | target-type-identifier |
YIN Element | 1 |
Version | 2010-12-10 |
File | ietf-complex-types |
Line | 84 |
Reference | section 3.2., instance-type extension statement |
Source | ietf-complex-types.yang line 84 |
max-access
Summary
Name | max-access |
Module | ietf-yang-smiv2 |
Version | 2012-06-22 |
The max-access statement takes as an argument the MAX-ACCESS assigned to an SMIv2 object definition. The MAX-ACCESS value is SMIv2 specific and has no impact on the access provided to YANG objects through protocols such as NETCONF. |
Details
Argument | access |
YIN Element | 0 |
Version | 2012-06-22 |
File | ietf-yang-smiv2 |
Line | 77 |
Reference | RFC 2578: Structure of Management Information Version 2 (SMIv2) |
Source | ietf-yang-smiv2.yang line 77 |
metadata
Summary
Name | metadata |
Module | yuma-ncx |
Version | 2015-10-16 |
Used to define an XML attribute to be associated with a data-def-stmt node. Only optional metadata can be defined. Errors for missing XML attributes (except as specified by the YANG language) will not be checked automatically. The syntax string has the following format: [prefix:]typename attribute-name Any YANG typedef of builtin type can be specified as the type name, except 'empty'. Example from get command in netconf.yang: ncx:metadata 'FilterType type'; |
Details
Argument | syntax-string |
YIN Element | 1 |
Version | 2015-10-16 |
File | yuma-ncx |
Line | 523 |
Source | yuma-ncx.yang line 523 |
mount-point
Summary
Name | mount-point |
Module | ietf-yang-schema-mount |
Version | 2019-01-14 |
The argument 'label' is a YANG identifier, i.e., it is of the type 'yang:yang-identifier'. The 'mount-point' statement MUST NOT be used in a YANG version 1 module, neither explicitly nor via a 'uses' statement. The 'mount-point' statement MAY be present as a substatement of 'container' and 'list' and MUST NOT be present elsewhere. There MUST NOT be more than one 'mount-point' statement in a given 'container' or 'list' statement. If a mount point is defined within a grouping, its label is bound to the module where the grouping is used. A mount point defines a place in the node hierarchy where other data models may be attached. A server that implements a module with a mount point populates the '/schema-mounts/mount-point' list with detailed information on which data models are mounted at each mount point. Note that the 'mount-point' statement does not define a new data node. |
Details
Argument | label |
YIN Element | 0 |
Version | 2019-01-14 |
File | ietf-yang-schema-mount |
Line | 67 |
Source | ietf-yang-schema-mount.yang line 67 |
name
Summary
Name | name |
Module | ieee1906-dot1-math |
Version | 2020-07-07 |
An optional name to use an equation as an unknown for functional programming. The name MUST be of type function:variableName. |
Details
Argument | name |
YIN Element | 0 |
Version | 2020-07-07 |
File | ieee1906-dot1-math |
Line | 120 |
Source | ieee1906-dot1-math.yang line 120 |
no-duplicates
Summary
Name | no-duplicates |
Module | yuma-ncx |
Version | 2015-10-16 |
Used to indicate that no duplicate values are allowed in an ncx:xsdlist leaf or leaf-list object. |
Details
Version | 2015-10-16 |
File | yuma-ncx |
Line | 546 |
Source | yuma-ncx.yang line 546 |
no-nvstore
Summary
Name | no-nvstore |
Module | yumaworks-extensions |
Version | 2020-03-31 |
Used within a configuration data node definition statement to indicate that configuration changes made to the object will not be stored in non-volatile storage. The configuration node will be handled in an implementation-specific manner. There is no argument defined for this extension. The extension applies to the specified node and all its descendants. |
Details
Version | 2020-03-31 |
File | yumaworks-extensions |
Line | 250 |
Source | yumaworks-extensions.yang line 250 |
no-sil-delete-children-first
Summary
Name | no-sil-delete-children-first |
Module | yumaworks-extensions |
Version | 2020-03-31 |
Used within a configuration data node definition statement to indicate that the --sil-delete-children-first parameter should be ignored for this subtree, if it is set to 'true'. Faster server performance can be achieved by deleting an entire subtree at once, and this extension allows the developer to force this behavior for the selected SIL libraries that can support such deletion. This is the opposite of the sil-delete-children-first extension. Note that this extension applies to the entire subtree, not just the node that contains this extension. There are no parameters defined. |
Details
Version | 2020-03-31 |
File | yumaworks-extensions |
Line | 261 |
Source | yumaworks-extensions.yang line 261 |
oid
Summary
Name | oid |
Module | ietf-yang-smiv2 |
Version | 2012-06-22 |
The oid statement takes as an argument the object identifier assigned to an SMIv2 definition. The object identifier value is written in decimal dotted notation. |
Details
Argument | value |
YIN Element | 0 |
Version | 2012-06-22 |
File | ietf-yang-smiv2 |
Line | 122 |
Reference | RFC 2578: Structure of Management Information Version 2 (SMIv2) |
Source | ietf-yang-smiv2.yang line 122 |
openconfig-encrypted-value
Summary
Name | openconfig-encrypted-value |
Module | openconfig-extensions |
Version | 2017-01-29 |
This extension provides an annotation on schema nodes to indicate that the corresponding value should be stored and reported in encrypted form. Clients reading the configuration or applied configuration for the node should expect to receive only the encrypted value. This annotation may be used on nodes such as secure passwords in which the device never reports a cleartext value, even if the input is provided as cleartext. |
Details
Version | 2017-01-29 |
File | openconfig-extensions |
Line | 77 |
Source | openconfig-extensions.yang line 77 |
openconfig-hashed-value
Summary
Name | openconfig-hashed-value |
Module | openconfig-extensions |
Version | 2020-06-16 |
This extension provides an annotation on schema nodes to indicate that the corresponding value should be stored and reported in hashed form. Hash algorithms are by definition not reversible. Clients reading the configuration or applied configuration for the node should expect to receive only the hashed value. Values written in cleartext will be hashed. This annotation may be used on nodes such as secure passwords in which the device never reports a cleartext value, even if the input is provided as cleartext. |
Details
Version | 2020-06-16 |
File | openconfig-extensions |
Line | 92 |
Source | openconfig-extensions.yang line 92 |
openconfig-hashed-value
Summary
Name | openconfig-hashed-value |
Module | openconfig-extensions |
Version | 2017-04-11 |
This extension provides an annotation on schema nodes to indicate that the corresponding value should be stored and reported in hashed form. Hash algorithms are by definition not reversible. Clients reading the configuration or applied configuration for the node should expect to receive only the hashed value. Values written in cleartext will be hashed. This annotation may be used on nodes such as secure passwords in which the device never reports a cleartext value, even if the input is provided as cleartext. |
Details
Version | 2017-04-11 |
File | openconfig-extensions |
Line | 71 |
Source | openconfig-extensions.yang line 71 |
openconfig-version
Summary
Name | openconfig-version |
Module | openconfig-extensions |
Version | 2017-01-29 |
The OpenConfig version number for the module. This is expressed as a semantic version number of the form: x.y.z where: * x corresponds to the major version, * y corresponds to a minor version, * z corresponds to a patch version. This version corresponds to the model file within which it is defined, and does not cover the whole set of OpenConfig models. Where several modules are used to build up a single block of functionality, the same module version is specified across each file that makes up the module. A major version number of 0 indicates that this model is still in development (whether within OpenConfig or with industry partners), and is potentially subject to change. Following a release of major version 1, all modules will increment major revision number where backwards incompatible changes to the model are made. The minor version is changed when features are added to the model that do not impact current clients use of the model. The patch-level version is incremented when non-feature changes (such as bugfixes or clarifications to human-readable descriptions that do not impact model functionality) are made that maintain backwards compatibility. The version number is stored in the module meta-data. |
Details
Argument | semver |
YIN Element | 0 |
Version | 2017-01-29 |
File | openconfig-extensions |
Line | 40 |
Source | openconfig-extensions.yang line 40 |
openconfig-version
Summary
Name | openconfig-version |
Module | openconfig-extensions |
Version | 2020-06-16 |
The OpenConfig version number for the module. This is expressed as a semantic version number of the form: x.y.z where: * x corresponds to the major version, * y corresponds to a minor version, * z corresponds to a patch version. This version corresponds to the model file within which it is defined, and does not cover the whole set of OpenConfig models. Individual YANG modules are versioned independently -- the semantic version is generally incremented only when there is a change in the corresponding file. Submodules should always have the same semantic version as their parent modules. A major version number of 0 indicates that this model is still in development (whether within OpenConfig or with industry partners), and is potentially subject to change. Following a release of major version 1, all modules will increment major revision number where backwards incompatible changes to the model are made. The minor version is changed when features are added to the model that do not impact current clients use of the model. The patch-level version is incremented when non-feature changes (such as bugfixes or clarifications to human-readable descriptions that do not impact model functionality) are made that maintain backwards compatibility. The version number is stored in the module meta-data. |
Details
Argument | semver |
YIN Element | 0 |
Version | 2020-06-16 |
File | openconfig-extensions |
Line | 53 |
Source | openconfig-extensions.yang line 53 |
openconfig-version
Summary
Name | openconfig-version |
Module | openconfig-extensions |
Version | 2017-04-11 |
The OpenConfig version number for the module. This is expressed as a semantic version number of the form: x.y.z where: * x corresponds to the major version, * y corresponds to a minor version, * z corresponds to a patch version. This version corresponds to the model file within which it is defined, and does not cover the whole set of OpenConfig models. Where several modules are used to build up a single block of functionality, the same module version is specified across each file that makes up the module. A major version number of 0 indicates that this model is still in development (whether within OpenConfig or with industry partners), and is potentially subject to change. Following a release of major version 1, all modules will increment major revision number where backwards incompatible changes to the model are made. The minor version is changed when features are added to the model that do not impact current clients use of the model. The patch-level version is incremented when non-feature changes (such as bugfixes or clarifications to human-readable descriptions that do not impact model functionality) are made that maintain backwards compatibility. The version number is stored in the module meta-data. |
Details
Argument | semver |
YIN Element | 0 |
Version | 2017-04-11 |
File | openconfig-extensions |
Line | 34 |
Source | openconfig-extensions.yang line 34 |
operational
Summary
Name | operational |
Module | openconfig-extensions |
Version | 2020-06-16 |
The operational annotation is specified in the context of a grouping, leaf, or leaf-list within a YANG module. It indicates that the nodes within the context are derived state on the device. OpenConfig data models divide nodes into the following three categories: - intended configuration - these are leaves within a container named 'config', and are the writable configuration of a target. - applied configuration - these are leaves within a container named 'state' and are the currently running value of the intended configuration. - derived state - these are the values within the 'state' container which are not part of the applied configuration of the device. Typically, they represent state values reflecting underlying operational counters, or protocol statuses. |
Details
Version | 2020-06-16 |
File | openconfig-extensions |
Line | 159 |
Source | openconfig-extensions.yang line 159 |
origin
Summary
Name | origin |
Module | openconfig-extensions |
Version | 2020-06-16 |
This extension specifies the name of the origin that the YANG module falls within. This allows multiple overlapping schema trees to be used on a single network element without requiring module based prefixing of paths. |
Details
Argument | origin |
YIN Element | 0 |
Version | 2020-06-16 |
File | openconfig-extensions |
Line | 188 |
Source | openconfig-extensions.yang line 188 |
password
Summary
Name | password |
Module | yuma-ncx |
Version | 2015-10-16 |
Used to indicate the data type for the leaf is really a password. For yangcli-pro, this extension causes a password to be printed as ****. For netconfd-pro this extension has the following effects: - In subtree filtering, a content-match node will skip over the node and not attempt to compare it to the content-match value. - In XPath filtering, a predicate comparison will skip over the node and not attempt to compare it to the content-match value. - Logging output that uses val_dump_value or val_sprintf_simval_nc will print **** instead of the password value. - In <get> and <get-config> responses, the string **** will be returned for the data node value. |
Details
Version | 2015-10-16 |
File | yuma-ncx |
Line | 552 |
Source | yuma-ncx.yang line 552 |
posix-pattern
Summary
Name | posix-pattern |
Module | openconfig-extensions |
Version | 2020-06-16 |
Provides a POSIX ERE regular expression pattern statement as an alternative to YANG regular expresssions based on XML Schema Datatypes. It is used the same way as the standard YANG pattern statement defined in RFC6020 and RFC7950, but takes an argument that is a POSIX ERE regular expression string. |
Details
Argument | pattern |
YIN Element | 0 |
Version | 2020-06-16 |
File | openconfig-extensions |
Line | 114 |
Reference | POSIX Extended Regular Expressions (ERE) Specification: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_04 |
Source | openconfig-extensions.yang line 114 |
qname
Summary
Name | qname |
Module | yuma-ncx |
Version | 2015-10-16 |
Used to indicate that the content of a data type is a Qualified Name. This is needed to properly evaluate the namespace prefix, if used. The qname extension may appear within the type-stmt, within a typedef, leaf, or leaf-list. The builtin data type must be 'string', or the 'qname' extension will be ignored. |
Details
Version | 2015-10-16 |
File | yuma-ncx |
Line | 672 |
Source | yuma-ncx.yang line 672 |
regexp-posix
Summary
Name | regexp-posix |
Module | openconfig-extensions |
Version | 2020-06-16 |
This extension indicates that the regular expressions included within the YANG module specified are conformant with the POSIX regular expression format rather than the W3C standard that is specified by RFC6020 and RFC7950. |
Details
Version | 2020-06-16 |
File | openconfig-extensions |
Line | 106 |
Source | openconfig-extensions.yang line 106 |
related-state
Summary
Name | related-state |
Module | ietf-yang-related-state |
Version | 2016-02-02 |
The related-state statement is used to identify a node that contains additional operational state associated for a config true node. The format of the argument is the same as for a leafref's 'path' statement. The related-state statement can be specified in the following YANG statements: o leaf o leaf-list o container o list The related-state statement allows the following YANG substatements: o description Multiple related-state statements can be given in a specific node. |
Details
Argument | path |
YIN Element | 0 |
Version | 2016-02-02 |
File | ietf-yang-related-state |
Line | 29 |
Source | ietf-yang-related-state.yang line 29 |
root
Summary
Name | root |
Module | yuma-ncx |
Version | 2015-10-16 |
Used within a container definition to indicate it is really a root container for a conceptual NETCONF database, instead of just an empty container. This is needed for yuma to correctly process any RPC method that contains a 'config' parameter. |
Details
Version | 2015-10-16 |
File | yuma-ncx |
Line | 580 |
Source | yuma-ncx.yang line 580 |
rpc-root
Summary
Name | rpc-root |
Module | yumaworks-extensions |
Version | 2020-03-31 |
Used within a container definition to indicate it is really a root container for a conceptual NETCONF operations, instead of just a container. The container is expected to be empty. Any top-level rpc-stmt can be specified using a QName value with the same module and local name as the RPC operation definition. This extension is reserved and only used by the server. |
Details
Version | 2020-03-31 |
File | yumaworks-extensions |
Line | 107 |
Source | yumaworks-extensions.yang line 107 |
schema-instance
Summary
Name | schema-instance |
Module | yuma-ncx |
Version | 2015-10-16 |
Used to indicate that the typedef or type statement for a string data type really identifies a special schema-instance node, not a generic string. A schema-instance value string is an unrestricted YANG instance-identifier expression. All the same rules as an instance-identifier apply except: * predicates for keys are optional; The dataRule will apply to all instances of any missing key leaf predicate. This extension will be ignored unless it is present in the type-stmt of a typedef-stmt, leaf-stmt, or leaf-list-stmt, or directly within a leaf-stmt or leaf-list-stmt. |
Details
Version | 2015-10-16 |
File | yuma-ncx |
Line | 684 |
Source | yuma-ncx.yang line 684 |
secure
Summary
Name | secure |
Module | yuma-nacm |
Version | 2012-10-05 |
Used to indicate that the data model node represents a sensitive security system parameter. If present, the NETCONF server will only allow the designated 'superuser' to have write or execute default nacm-rights for the node. An explicit access control rule is required for all other users. The 'secure' extension may appear within a data, rpc, or notification node definition. It is ignored otherwise. |
Details
Version | 2012-10-05 |
File | yuma-nacm |
Line | 142 |
Source | yuma-nacm.yang line 142 |
secure
Summary
Name | secure |
Module | nacm |
Version | 2010-09-02 |
Used to indicate that the data model node represents a sensitive security system parameter. If present, the NETCONF server will only allow the designated 'superuser' to have write or execute default nacm-rights-type for the node. An explicit access control rule is required for all other users. The 'secure' extension may appear within a data, rpc, or notification node definition. It is ignored otherwise. |
Details
Version | 2010-09-02 |
File | nacm |
Line | 33 |
Source | nacm.yang line 33 |
sil-aio-get2
Summary
Name | sil-aio-get2 |
Module | yumaworks-extensions |
Version | 2020-03-31 |
Used within a data definition statement to define the GET2 retrieval mechanism. This extension affects the descendant data nodes. This extension can be used in a container or list to force the server to treat that data subtree as a terminal node for GET2. The entire subtree would be expected in one retrieval in one callback invocation. The entire subtree can be specified in the JSON or XML buffer that will be used for return values. The server will parse and handle the buffer and process retrieval based on the provide JSON or XML encoded buffer. The 'parmstr' argument can specify the encoding that will be used in the callback. Available options are: - xml - json If not specified default val value retrieval mechanism will be assumed. |
Details
Argument | parmstr |
YIN Element | 0 |
Version | 2020-03-31 |
File | yumaworks-extensions |
Line | 399 |
Source | yumaworks-extensions.yang line 399 |
sil-delete-children-first
Summary
Name | sil-delete-children-first |
Module | yuma-ncx |
Version | 2015-10-16 |
Used within a container or list definition to indicate that the SIL callbacks for descendant nodes should be invoked first, when a data node instance of the object containing this extension is deleted. Normally, the parent node is expected to delete all its own sub-structures when the SIL edit callback is invoked. If this extension is present, then any SIL callbacks for any of the child nodes will be invoked first instead. If a child node is a list or a container, and it also contains an 'ncx:sil-delete-children-first' extension, then its children will be checked first. The SIL edit callback will not be invoked for leaf, leaf-list, or anyxml descendant nodes in this mode. They will only will called if their parent node is not getting deleted. container foo { ncx:sil-delete-children-first; list foos { ncx:sil-delete-children-first; key a; leaf a { type string; } container b { list c { ... } } leaf d { type empty; } } } In this example, assume node /foo gets deleted. Then the SIL edit callbacks would be done as follows: 1) /foo/foos[a='n']/b (called for row 'n' of /foo/foos) 2) /foo/foos[a='n'] (called for row 'n' of /foo/foos) 3) repeat (1,2) until all rows in /foo/foos are deleted 4) /foo Note that the SIL edit callback is not done for list /foo/foos[a='n']/b/c because this extension is not present in container '/foo/foos/b'. Note that the SIL edit callback is not done for nodes /foo/foos[a='n']/a or /foo/foos[a='n']/d because they are leafs. |
Details
Version | 2015-10-16 |
File | yuma-ncx |
Line | 589 |
Source | yuma-ncx.yang line 589 |
sil-force-replace-replay
Summary
Name | sil-force-replace-replay |
Module | yumaworks-extensions |
Version | 2020-03-31 |
Used within a configuration data node definition statement to indicate that the SIL (or SIL-SA) callback should be invoked even for nodes that are not changing, during a replace operation. All SIL callbacks for child nodes in the replace request (where the parent node contains this extension) will be invoked during edit processing. If this extension is used within a list statement, then SIL callbacks for all instances of the list that are provided in the replace operation will be invoked. |
Details
Version | 2020-03-31 |
File | yumaworks-extensions |
Line | 206 |
Source | yumaworks-extensions.yang line 206 |
sil-force-replay
Summary
Name | sil-force-replay |
Module | yumaworks-extensions |
Version | 2020-03-31 |
Used within a configuration data node definition statement to indicate that the SIL (or SIL-SA) callback should be invoked even for nodes that are not changing. At least one descendant-or-self node must be changing in order for any of the SIL callbacks for unchanged sibling nodes to be invoked. |
Details
Version | 2020-03-31 |
File | yumaworks-extensions |
Line | 196 |
Source | yumaworks-extensions.yang line 196 |
sil-priority
Summary
Name | sil-priority |
Module | yumaworks-extensions |
Version | 2020-03-31 |
Used to control the order that SIL or SIL-SA callbacks are invoked for specific objects. If this extension is used within a configuration database object then the SIL priority for the object will be assigned the value of the 'prio' argument. Only the order of the 'apply', 'commit' and 'rollback' callback phases will be affected by this parameter. The 'validate' phase callbacks are invoked in the order they appear in the edit request. The 'prio' argument must be a number between 1 and 255. If two objects are edited in the same edit request, the the one with the lowest SIL priority number will be executed first. If no sil-priority is set for an object, then the value of its nearest ancestor with the sil-priority extension set will be used. If there is none, the the default value of '255' will be used. If the SIL priority is the same for two objects in the same edit request, then the server will pick an order in an implementation-specific manner. |
Details
Argument | prio |
YIN Element | 0 |
Version | 2020-03-31 |
File | yumaworks-extensions |
Line | 220 |
Source | yumaworks-extensions.yang line 220 |
sil-test-get-when
Summary
Name | sil-test-get-when |
Module | yumaworks-extensions |
Version | 2020-03-31 |
Used within a data definition statement to define the --sil-get-test-when CLI parameter behavior for a single object. This extension does not affect the descendant data nodes. The 'boolval' argument must be the string 'true' or 'false'; If 'true' the object will be tested for when-stmts if any need to be evaluated during retrieval operations. If 'false' then any when-stmts will be ignored during retrieval operations. This extension will override the --sil-test-get-when global CLI parameter. This extension will have no affect unless the value is different than this CLI parameter. |
Details
Argument | boolval |
YIN Element | 0 |
Version | 2020-03-31 |
File | yumaworks-extensions |
Line | 379 |
Source | yumaworks-extensions.yang line 379 |
structure
Summary
Name | structure |
Module | ietf-yang-structure-ext |
Version | 2020-06-17 |
This extension is used to specify a YANG data structure that represents conceptual data defined in YANG. It is intended to describe hierarchical data independent of protocol context or specific message encoding format. Data definition statements within a 'structure' extension statement specify the generic syntax for the specific YANG data structure, whose name is the argument of the 'structure' extension statement. Note that this extension does not define a media type. A specification using this extension MUST specify the message encoding rules, including the content media type, if applicable. The mandatory 'name' parameter value identifies the YANG data structure that is being defined. This extension is only valid as a top-level statement, i.e., given as a substatement to 'module' or 'submodule'. The substatements of this extension MUST follow the ABNF rules below, where the rules are defined in RFC 7950: *must-stmt [status-stmt] [description-stmt] [reference-stmt] *(typedef-stmt / grouping-stmt) *data-def-stmt A YANG data structure defined with this extension statement is encoded in the same way as an 'anydata' node. This means that the name of the structure is encoded as a 'container', with the instantiated child statements encoded as child nodes to this node. The module name and namespace value for the YANG module using the extension statement are assigned to each of the data definition statements resulting from the YANG data structure. The XPath document element is the extension statement itself, such that the child nodes of the document element are represented by the data-def-stmt substatements within this extension. This conceptual document is the context for the following YANG statements: - must-stmt - when-stmt - path-stmt - min-elements-stmt - max-elements-stmt - mandatory-stmt - unique-stmt - ordered-by - instance-identifier data type The following data-def-stmt substatements are constrained when used within a 'structure' extension statement. - The list-stmt is not required to have a key-stmt defined. - The config-stmt is ignored if present. |
Details
Argument | name |
YIN Element | 1 |
Version | 2020-06-17 |
File | ietf-yang-structure-ext |
Line | 51 |
Source | ietf-yang-structure-ext.yang line 51 |
subid
Summary
Name | subid |
Module | ietf-yang-smiv2 |
Version | 2012-06-22 |
The subid statement takes as an argument the last sub-identifier of the object identifier assigned to an SMIv2 definition. The sub-identifier value is a single positive decimal natural number. The subid statement may not be used as a substatement to any top-level node in a YANG document. The subid substatement may be used only as a substatement to a node having a parent node defined with either an smiv2:oid or smiv2:subid substatement. |
Details
Argument | value |
YIN Element | 0 |
Version | 2012-06-22 |
File | ietf-yang-smiv2 |
Line | 132 |
Reference | RFC 2578: Structure of Management Information Version 2 (SMIv2) |
Source | ietf-yang-smiv2.yang line 132 |
subscription-state-notification
Summary
Name | subscription-state-notification |
Module | ietf-subscribed-notifications |
Version | 2019-09-09 |
This statement applies only to notifications. It indicates that the notification is a subscription state change notification. Therefore, it does not participate in a regular event stream and does not need to be specifically subscribed to in order to be received. This statement can only occur as a substatement of the YANG 'notification' statement. This statement is not for use outside of this YANG module. |
Details
Version | 2019-09-09 |
File | ietf-subscribed-notifications |
Line | 171 |
Source | ietf-subscribed-notifications.yang line 171 |
symbol
Summary
Name | symbol |
Module | ieee1906-dot1-math |
Version | 2020-07-07 |
To provide a known name that represents this type. Adds nothing to a NETCONF server. |
Details
Argument | symbol-name |
YIN Element | 0 |
Version | 2020-07-07 |
File | ieee1906-dot1-math |
Line | 100 |
Source | ieee1906-dot1-math.yang line 100 |
telemetry-atomic
Summary
Name | telemetry-atomic |
Module | openconfig-extensions |
Version | 2020-06-16 |
The telemetry-atomic annotation is specified in the context of a subtree (containre, or list), and indicates that all nodes within the subtree are always updated together within the data model. For example, all elements under the subtree may be updated as a result of a new alarm being raised, or the arrival of a new protocol message. Transport protocols may use the atomic specification to determine optimisations for sending or storing the corresponding data. |
Details
Version | 2020-06-16 |
File | openconfig-extensions |
Line | 146 |
Source | openconfig-extensions.yang line 146 |
telemetry-on-change
Summary
Name | telemetry-on-change |
Module | openconfig-extensions |
Version | 2020-06-16 |
The telemetry-on-change annotation is specified in the context of a particular subtree (container, or list) or leaf within the YANG schema. Where specified, it indicates that the value stored by the nodes within the context change their value only in response to an event occurring. The event may be local to the target, for example - a configuration change, or external - such as the failure of a link. When a telemetry subscription allows the target to determine whether to export the value of a leaf in a periodic or event-based fashion (e.g., TARGET_DEFINED mode in gNMI), leaves marked as telemetry-on-change should only be exported when they change, i.e., event-based. |
Details
Version | 2020-06-16 |
File | openconfig-extensions |
Line | 129 |
Source | openconfig-extensions.yang line 129 |
units
Summary
Name | units |
Module | ieee1906-dot1-si-units |
Version | 2020-07-07 |
To provide a unit to logical functions, such as groupings. A container can be made of leafs, and have a unit on its own. |
Details
Argument | name |
YIN Element | 0 |
Version | 2020-07-07 |
File | ieee1906-dot1-si-units |
Line | 135 |
Source | ieee1906-dot1-si-units.yang line 135 |
urlpath
Summary
Name | urlpath |
Module | yumaworks-extensions |
Version | 2020-03-31 |
Used within a leaf or leaf-list definition to indicate it is really a REST URI path string, not a plain string. |
Details
Version | 2020-03-31 |
File | yumaworks-extensions |
Line | 118 |
Source | yumaworks-extensions.yang line 118 |
user-write
Summary
Name | user-write |
Module | yuma-ncx |
Version | 2015-10-16 |
Used within database configuration data definition statements to control user write access to the database object containing this statement. The 'exceptions' argument is a list of operations that users are permitted to invoke for the specified node. These permissions will over-ride all NACM access control rules, even if NACM is disabled. This extension does not apply to descendant nodes! This extension has no effect if config-stmt is false! The following values are supported: * create : allow users to create instances of the object * update : allow users to modify instances of the object * delete : allow users to delete instances of the object To dis-allow all user access, provide an empty string for the 'exceptions' argument (user-write '';) To allow only create and delete user access, provide the string 'create delete' for the 'exceptions' parameter. Use this for parameters that cannot be changed once they are set. Providing all 3 parameters has the same affect as not using this extension at all, but can be used anyway. leaf user-write { type bits { bit create; bit update; bit delete; } default 'create update delete'; description 'equivalent YANG definition'; } |
Details
Argument | exceptions |
YIN Element | 1 |
Version | 2015-10-16 |
File | yuma-ncx |
Line | 704 |
Source | yuma-ncx.yang line 704 |
value
Summary
Name | value |
Module | ieee1906-dot1-math |
Version | 2020-07-07 |
The value part of the equation which MUST be of type function:variable. The result of the equation. It can be used to directly configure the server. Or the value is returned by the server as a result of a call, a simulation, a mathematical process. This is a variable. A numerical value can be provided. Or, if it is unknown, or in case of functional programming, the target variable name can be used instead. |
Details
Version | 2020-07-07 |
File | ieee1906-dot1-math |
Line | 107 |
Source | ieee1906-dot1-math.yang line 107 |
very-secure
Summary
Name | very-secure |
Module | yuma-nacm |
Version | 2012-10-05 |
Used to indicate that the data model node controls a very sensitive security system parameter. If present, the NETCONF server will only allow the designated 'superuser' to have read, write, or execute default nacm-rights for the node. An explicit access control rule is required for all other users. The 'very-secure' extension may appear within a data, rpc, or notification node definition. It is ignored otherwise. |
Details
Version | 2012-10-05 |
File | yuma-nacm |
Line | 157 |
Source | yuma-nacm.yang line 157 |
very-secure
Summary
Name | very-secure |
Module | nacm |
Version | 2010-09-02 |
Used to indicate that the data model node controls a very sensitive security system parameter. If present, the NETCONF server will only allow the designated 'superuser' to have read, write, or execute default nacm-rights-type for the node. An explicit access control rule is required for all other users. The 'very-secure' extension may appear within a data, rpc, or notification node definition. It is ignored otherwise. |
Details
Version | 2010-09-02 |
File | nacm |
Line | 48 |
Source | nacm.yang line 48 |
xpath
Summary
Name | xpath |
Module | yuma-ncx |
Version | 2015-10-16 |
Used to indicate that the content of a data type is an XPath expression. This is needed to properly evaluate the namespace prefixes within the expression. The xpath extension may appear within the type-stmt, within a typedef, leaf, or leaf-list. The builtin data type must be 'string', or the 'xpath' extension will be ignored. All data using the 'instance-identifier' built-in type will automatically be processed as an XPath string, so the xpath extension is not needed in that case. |
Details
Version | 2015-10-16 |
File | yuma-ncx |
Line | 656 |
Source | yuma-ncx.yang line 656 |
xpath-operational-ok
Summary
Name | xpath-operational-ok |
Module | yumaworks-extensions |
Version | 2020-03-31 |
Used within a data-definition statement for a configuration data node to alter the must-stmt and when-stmt found within the data node. This allows an XPath expression in such a node to reference config=false data nodes. This property does not apply to any child nodes, just the data node containing this external statement. This violates the standard in RFC 7950, sec 6.4.1 so use with caution since the YANG module will not be valid according to YANG 1.1 rules. There is no parameter for this extension. |
Details
Version | 2020-03-31 |
File | yumaworks-extensions |
Line | 428 |
Source | yumaworks-extensions.yang line 428 |
xsdlist
Summary
Name | xsdlist |
Module | yuma-ncx |
Version | 2015-10-16 |
Used to indicate the leaf string type is really an XSD list, which is a series of whitespace separated strings. The type argument represents the data type to use for the list members, for validation purposes. Allowed to be present within the type sub-section for a string. |
Details
Argument | type |
YIN Element | 1 |
Version | 2015-10-16 |
File | yuma-ncx |
Line | 642 |
Source | yuma-ncx.yang line 642 |
yang-data
Summary
Name | yang-data |
Module | ietf-restconf |
Version | 2017-01-26 |
This extension is used to specify a YANG data template that represents conceptual data defined in YANG. It is intended to describe hierarchical data independent of protocol context or specific message-encoding format. Data definition statements within a yang-data extension specify the generic syntax for the specific YANG data template, whose name is the argument of the 'yang-data' extension statement. Note that this extension does not define a media type. A specification using this extension MUST specify the message-encoding rules, including the content media type. The mandatory 'name' parameter value identifies the YANG data template that is being defined. It contains the template name. This extension is ignored unless it appears as a top-level statement. It MUST contain data definition statements that result in exactly one container data node definition. An instance of a YANG data template can thus be translated into an XML instance document, whose top-level element corresponds to the top-level container. The module name and namespace values for the YANG module using the extension statement are assigned to instance document data conforming to the data definition statements within this extension. The substatements of this extension MUST follow the 'data-def-stmt' rule in the YANG ABNF. The XPath document root is the extension statement itself, such that the child nodes of the document root are represented by the data-def-stmt substatements within this extension. This conceptual document is the context for the following YANG statements: - must-stmt - when-stmt - path-stmt - min-elements-stmt - max-elements-stmt - mandatory-stmt - unique-stmt - ordered-by - instance-identifier data type The following data-def-stmt substatements are constrained when used within a 'yang-data' extension statement. - The list-stmt is not required to have a key-stmt defined. - The if-feature-stmt is ignored if present. - The config-stmt is ignored if present. - The available identity values for any 'identityref' leaf or leaf-list nodes are limited to the module containing this extension statement and the modules imported into that module. |
Details
Argument | name |
YIN Element | 1 |
Version | 2017-01-26 |
File | ietf-restconf |
Line | 53 |
Source | ietf-restconf.yang line 53 |