netconfcentral logo

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