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

addend

Summary

Name addend
Module ietf-math-types
Version 2017-09-12
  
 
Define a addend node

Details

Argument name
YIN Element 0
Version 2017-09-12
File ietf-math-types
Line 23
Source ietf-math-types.yang line 23

addition

Summary

Name addition
Module ietf-math-types
Version 2017-09-12
  
 
Define a addition expression node

Details

Argument name
YIN Element 0
Version 2017-09-12
File ietf-math-types
Line 19
Source ietf-math-types.yang line 19

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 116
Reference RFC 2578: Structure of Management Information Version 2 (SMIv2)
Source ietf-yang-smiv2.yang line 116

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 2015-05-08
  
 
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
altername name to use.  It must be a valid YANG identifier.

Details

Argument name
YIN Element 0
Version 2015-05-08
File yumaworks-extensions
Line 64
Source yumaworks-extensions.yang line 64

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

augment-yang-data

Summary

Name augment-yang-data
Module yang-data-ext
Version 2017-10-30
  
 
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.

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-10-30
File yang-data-ext
Line 117
Source yang-data-ext.yang line 117

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 2015-05-08
  
 
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 2015-05-08
File yumaworks-extensions
Line 93
Source yumaworks-extensions.yang line 93

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

const

Summary

Name const
Module ietf-math-types
Version 2017-09-12
  
 
Define a const node

Details

Argument name
YIN Element 0
Version 2017-09-12
File ietf-math-types
Line 75
Source ietf-math-types.yang line 75

data-not-sensitive

Summary

Name data-not-sensitive
Module ietf-i2rs-ephemeral-ds
Version 2017-11-11
  
 
This extension indicates that this
       read-only data node is not sensitive
       and should be allowed to
       access via a non-secure transport.
       The value is either true or false.
       

Details

Argument value
YIN Element 0
Version 2017-11-11
File ietf-i2rs-ephemeral-ds
Line 75
Source ietf-i2rs-ephemeral-ds.yang line 75

datapath

Summary

Name datapath
Module yumaworks-extensions
Version 2015-05-08
  
 
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 2015-05-08
File yumaworks-extensions
Line 141
Source yumaworks-extensions.yang line 141

default

Summary

Name default
Module yang-smi
Version 2008-03-20
  
 
DEFVAL value provided in an OBJECT-TYPE macro.

Details

Argument default
YIN Element 0
Version 2008-03-20
File yang-smi
Line 34
Source yang-smi.yang line 34

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 74
Source ietf-netconf-acm.yang line 74

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 2017-12-11
  
 
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 2017-12-11
File ietf-netconf-acm
Line 78
Source ietf-netconf-acm.yang line 78

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 59
Source ietf-netconf-acm.yang line 59

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 2017-12-11
  
 
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 2017-12-11
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 94
Reference RFC 2578: Structure of Management Information Version 2 (SMIv2)
Source ietf-yang-smiv2.yang line 94

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

display-hint

Summary

Name display-hint
Module yang-smi
Version 2008-03-20
  
 
DISPLAY-HINT value provided in a TEXTUAL-CONVENTION macro.

Details

Argument hint
YIN Element 0
Version 2008-03-20
File yang-smi
Line 28
Source yang-smi.yang line 28

dividend

Summary

Name dividend
Module ietf-math-types
Version 2017-09-12
  
 
Define a dividend node

Details

Argument name
YIN Element 0
Version 2017-09-12
File ietf-math-types
Line 55
Source ietf-math-types.yang line 55

division

Summary

Name division
Module ietf-math-types
Version 2017-09-12
  
 
Define a division expression node

Details

Argument name
YIN Element 0
Version 2017-09-12
File ietf-math-types
Line 47
Source ietf-math-types.yang line 47

divisor

Summary

Name divisor
Module ietf-math-types
Version 2017-09-12
  
 
Define a divisor node

Details

Argument name
YIN Element 0
Version 2017-09-12
File ietf-math-types
Line 51
Source ietf-math-types.yang line 51

event

Summary

Name event
Module ietf-math-types
Version 2017-09-12
  
 
Define a event node

Details

Argument name
YIN Element 0
Version 2017-09-12
File ietf-math-types
Line 59
Source ietf-math-types.yang line 59

exclusive-rpc

Summary

Name exclusive-rpc
Module yumaworks-extensions
Version 2015-05-08
  
 
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 2015-05-08
File yumaworks-extensions
Line 131
Source yumaworks-extensions.yang line 131

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

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 61
Source ietf-netconf.yang line 61

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

help

Summary

Name help
Module yumaworks-extensions
Version 2015-05-08
  
 
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 2015-05-08
File yumaworks-extensions
Line 117
Source yumaworks-extensions.yang line 117

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 106
Reference RFC 2578: Structure of Management Information Version 2 (SMIv2)
Source ietf-yang-smiv2.yang line 106

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

loop

Summary

Name loop
Module ietf-math-types
Version 2017-09-12
  
 
Define a loop node

Details

Argument name
YIN Element 0
Version 2017-09-12
File ietf-math-types
Line 63
Source ietf-math-types.yang line 63

math

Summary

Name math
Module ietf-math-types
Version 2017-09-12
  
 
Define a mathematical expression node

Details

Argument name
YIN Element 0
Version 2017-09-12
File ietf-math-types
Line 15
Source ietf-math-types.yang line 15

max

Summary

Name max
Module ietf-math-types
Version 2017-09-12
  
 
Define a max node

Details

Argument name
YIN Element 0
Version 2017-09-12
File ietf-math-types
Line 71
Source ietf-math-types.yang line 71

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 81
Reference RFC 2578: Structure of Management Information Version 2 (SMIv2)
Source ietf-yang-smiv2.yang line 81

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

min

Summary

Name min
Module ietf-math-types
Version 2017-09-12
  
 
Define a min node

Details

Argument name
YIN Element 0
Version 2017-09-12
File ietf-math-types
Line 67
Source ietf-math-types.yang line 67

minuend

Summary

Name minuend
Module ietf-math-types
Version 2017-09-12
  
 
Define a minuend node

Details

Argument name
YIN Element 0
Version 2017-09-12
File ietf-math-types
Line 31
Source ietf-math-types.yang line 31

mount-point

Summary

Name mount-point
Module ietf-yang-schema-mount
Version 2017-10-09
  
 
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 2017-10-09
File ietf-yang-schema-mount
Line 73
Source ietf-yang-schema-mount.yang line 73

mountpoint

Summary

Name mountpoint
Module ietf-mount
Version 2017-03-30
  
 
This YANG extension is used to mount data from another
subtree in place of the node under which this YANG extension
statement is used.

This extension takes one argument which specifies the name
of the mountpoint.

This extension can occur as a substatement underneath a
container statement, a list statement, or a case statement.
As a best practice, it SHOULD occur as statement only
underneath a container statement, but it MAY also occur
underneath a list or a case statement.

The extension can take two parameters, target and subtree,
each defined as their own YANG extensions.

For Alias-Mount, a mountpoint statement MUST contain a
subtree statement for the mountpoint definition to be valid.
For Peer-Mount, a mountpoint statement MUST contain both a
target and a subtree substatement for the mountpoint
definition to be valid.

The subtree SHOULD be specified in terms of a data node of
type 'mnt:subtree-ref'. The targeted data node MUST
represent a container.

The target system MAY be specified in terms of a data node
that uses the grouping 'mnt:mount-target'.  However, it
can be specified also in terms of any other data node that
contains sufficient information to address the mount target,
such as an IP address, a host name, or a URI.

It is possible for the mounted subtree to in turn contain a
mountpoint.  However, circular mount relationships MUST NOT
be introduced. For this reason, a mounted subtree MUST NOT
contain a mountpoint that refers back to the mounting system
with a mount target that directly or indirectly contains the
originating mountpoint.

Details

Argument name
YIN Element 0
Version 2017-03-30
File ietf-mount
Line 40
Source ietf-mount.yang line 40

multiplication

Summary

Name multiplication
Module ietf-math-types
Version 2017-09-12
  
 
Define a multiplication expression node

Details

Argument name
YIN Element 0
Version 2017-09-12
File ietf-math-types
Line 39
Source ietf-math-types.yang line 39

multiplier

Summary

Name multiplier
Module ietf-math-types
Version 2017-09-12
  
 
Define a multiplier node

Details

Argument name
YIN Element 0
Version 2017-09-12
File ietf-math-types
Line 43
Source ietf-math-types.yang line 43

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

notifiable-on-change

Summary

Name notifiable-on-change
Module ietf-yang-push
Version 2017-10-23
  
 
Indicates whether changes to the data node are reportable in
on-change subscriptions.

The statement MUST only be a substatement of the leaf, leaf-list,
container, list, anyxml, anydata  statements. Zero or One
notifiable-on-change statement is allowed per parent statement.
NO substatements are allowed.

The argument is a boolean value indicating whether on-change
notifications are supported. If notifiable-on-change is not
specified, the default is the same as the parent data node's
value. For top level data nodes the default value is false.

Details

Argument value
YIN Element 0
Version 2017-10-23
File ietf-yang-push
Line 60
Source ietf-yang-push.yang line 60

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 129
Reference RFC 2578: Structure of Management Information Version 2 (SMIv2)
Source ietf-yang-smiv2.yang line 129

oid

Summary

Name oid
Module yang-smi
Version 2008-03-20
  
 
OBJECT IDENTIFIER value assigned to a particular node.

Details

Argument oid
YIN Element 0
Version 2008-03-20
File yang-smi
Line 22
Source yang-smi.yang line 22

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 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 78
Source openconfig-extensions.yang line 78

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 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 41
Source openconfig-extensions.yang line 41

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

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

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 2015-05-08
  
 
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 2015-05-08
File yumaworks-extensions
Line 76
Source yumaworks-extensions.yang line 76

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

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 2015-05-08
  
 
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 2015-05-08
File yumaworks-extensions
Line 175
Source yumaworks-extensions.yang line 175

sil-force-replay

Summary

Name sil-force-replay
Module yumaworks-extensions
Version 2015-05-08
  
 
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 2015-05-08
File yumaworks-extensions
Line 165
Source yumaworks-extensions.yang line 165

sil-priority

Summary

Name sil-priority
Module yumaworks-extensions
Version 2015-05-08
  
 
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 2015-05-08
File yumaworks-extensions
Line 189
Source yumaworks-extensions.yang line 189

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 139
Reference RFC 2578: Structure of Management Information Version 2 (SMIv2)
Source ietf-yang-smiv2.yang line 139

subscription-state-notif

Summary

Name subscription-state-notif
Module ietf-subscribed-notifications
Version 2017-10-27
  
 
This statement applies only to notifications. It indicates that
the notification is a subscription state 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 to the YANG
'notification' statement.

Details

Version 2017-10-27
File ietf-subscribed-notifications
Line 93
Source ietf-subscribed-notifications.yang line 93

subtraction

Summary

Name subtraction
Module ietf-math-types
Version 2017-09-12
  
 
Define a subtraction expression node

Details

Argument name
YIN Element 0
Version 2017-09-12
File ietf-math-types
Line 27
Source ietf-math-types.yang line 27

subtrahend

Summary

Name subtrahend
Module ietf-math-types
Version 2017-09-12
  
 
Define a subtrahend node

Details

Argument name
YIN Element 0
Version 2017-09-12
File ietf-math-types
Line 35
Source ietf-math-types.yang line 35

subtree

Summary

Name subtree
Module ietf-mount
Version 2017-03-30
  
 
This YANG extension is used to specify a subtree in a
datastore that is to be mounted.  This YANG extension takes
one argument which specifies the path to the root of the
subtree. The root of the subtree SHOULD represent an
instance of a YANG container.  However, it MAY represent
also another data node.

This YANG extension can occur only as a substatement below
a mountpoint statement. It MUST NOT occur as a substatement
below any other YANG statement.

Details

Argument subtree-path
YIN Element 0
Version 2017-03-30
File ietf-mount
Line 101
Source ietf-mount.yang line 101

target

Summary

Name target
Module ietf-mount
Version 2017-03-30
  
 
This YANG extension is used to perform a Peer-Mount.
It is used to specify a remote target system from which to
mount a datastore subtree.  This YANG
extension takes one argument which specifies the remote
system. In general, this argument will contain the name of
a data node that contains the remote system information. It
is recommended that the reference data node uses the
mount-target grouping that is defined further below in this
module.

This YANG extension can occur only as a substatement below
a mountpoint statement. It MUST NOT occur as a substatement
below any other YANG statement.

Details

Argument target-name
YIN Element 0
Version 2017-03-30
File ietf-mount
Line 83
Source ietf-mount.yang line 83

text-media-type

Summary

Name text-media-type
Module ietf-yang-text-media-type
Version 2017-03-09
  
 
This extension allows for specifying a media type that is used
for markup in the arguments of the following YANG statements:

- contact

- description

- error-message

- organization
- reference

The *text-media-type* extension statement MAY be used at the
top level of a module or submodule, i.e., as a substatement of
*module* or *submodule*, and no more than once. The declared
media type applies throughout the module or submodule.

The argument SHOULD be a media type registered by IANA in the
*text* registry. Media type parameters MAY be present.

This YANG extension is only indicative and optional to
implement. Tools MAY ignore it completely or support just a
subset of markup directives that are available for a given
media type.

Details

Argument type
YIN Element 0
Version 2017-03-09
File ietf-yang-text-media-type
Line 57
Reference - IANA: Media Types, 2016-12-21. Available [online] (http://www.iana.org/assignments/media-types/media-types.xhtml) - [RFC 6838](https://tools.ietf.org/html/rfc6838): Media Type Specifications and Registration Procedures
Source ietf-yang-text-media-type.yang line 57

urlpath

Summary

Name urlpath
Module yumaworks-extensions
Version 2015-05-08
  
 
Used within a leaf or leaf-list definition to indicate it is
really a REST URI path string, not a plain string.

Details

Version 2015-05-08
File yumaworks-extensions
Line 87
Source yumaworks-extensions.yang line 87

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

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

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

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 which
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 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 sub-statements 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 sub-statements 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 sub-statements are constrained
when used within a yang-data-resource 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.

Details

Argument name
YIN Element 1
Version 2017-01-26
File ietf-restconf
Line 53
Source ietf-restconf.yang line 53

yang-data

Summary

Name yang-data
Module ietf-restconf
Version 2016-08-15
  
 
This extension is used to specify a YANG data template which
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 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 sub-statements 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 sub-statements 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 sub-statements are constrained
when used within a yang-data-resource 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.

Details

Argument name
YIN Element 1
Version 2016-08-15
File ietf-restconf
Line 61
Source ietf-restconf.yang line 61

yang-data

Summary

Name yang-data
Module yang-data-ext
Version 2017-10-30
  
 
This extension is used to specify a YANG data template which
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 parameter is only used for readability
purposes. There are no mechanisms to reuse yang-data by
its template name value.

This extension is ignored unless it appears as a top-level
statement. It MUST contain data definition statements
that result in a set of data definition statements.

If the yang data template is intended to be used as
a top-level structure, then the yang data template needs to
result in a single container, so an instance of the 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 value for the YANG module using
the extension statement is assigned to each of the data
definition statements resulting from the yang data template.
The name of each data definition statement resulting from
a yang data template is assigned to a top-level identifier name
in the data node identifier namespace, according to RFC 7950,
section 6.2.1.

The sub-statements 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 sub-statements 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 sub-statements are constrained
when used within a yang-data-resource 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.

Details

Argument name
YIN Element 1
Version 2017-10-30
File yang-data-ext
Line 43
Source yang-data-ext.yang line 43