Extensions

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.

Makes the complex-type abstract.

Makes the complex-type abstract.

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.

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

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.

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.

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.

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; }
      }
   }

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; }
      }
   }

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.

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.

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
 }

Defines a complex-type.

Defines a complex-type.

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>

Copy of IETF version of 'very-secure' extension.

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.

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.

Copy of IETF version of 'secure' extension.

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.

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.

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.

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'

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.

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).

The display-hint statement takes as an argument the DISPLAY-HINT
assigned to an SMIv2 textual convention.

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.

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';
     }
   }

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.

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.

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.

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.

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.

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.

Defines the base type of a complex-type.

Defines the base type of a complex-type.

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.

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.

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.

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. 

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.

Declares an instance of the given
complex type.

Declares an instance of the given
complex type.

Declares a list of instances of the given
complex type

Declares a list of instances of the given
complex type

Tells to which type instance the instance
identifier refers.

Tells to which type instance the instance
identifier refers to.

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.

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';   

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.

An optional name to use an equation as an unknown for functional programming.
The name MUST be of type function:variableName.

Used to indicate that no duplicate values are allowed
in an ncx:xsdlist leaf or leaf-list object.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

To provide a known name that represents this type. Adds nothing to a NETCONF
server.

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.

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.

To provide a unit to logical functions, such as groupings. A container can be
made of leafs, and have a unit on its own.

Used within a leaf or leaf-list definition to indicate it is
really a REST URI path string, not a plain string.

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';
}

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.

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.

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.

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.

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.

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.

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.