revision 2015-05-22 {
description
"Released as part of ConfD-5.4.2 / NCS-3.4.2.
-
+
Allow tailf:export and tailf:unique-selector in
tailf:annotate-module.";
}
revision 2015-03-19 {
description
"Released as part of ConfD-5.4 / NCS-3.4.
-
+
Added if-feature as substatement to tailf:annotate.
-
+
Added tailf:no-dependency.
-
+
Updated the description for tailf:dependency.
-
+
Allow tailf:id-value as substatement to 'module',
tailf:annotate-module, 'choice', and 'case'.";
}
revision 2014-11-13 {
description
"Released as part of ConfD-5.3 / NCS-3.3.
-
+
Added tailf:export.";
}
revision 2014-06-30 {
description
"Released as part of ConfD-5.2 / NCS-3.2.
-
+
Added tailf:sha-256-digest-string and tailf:sha-512-digest-string.";
}
revision 2014-03-27 {
description
"Released as part of ConfD-5.1 / NCS-3.1.
-
+
Added tailf:actionpoint as substatement to refine.
Removed must as substatement to tailf:symlink.";
}
revision 2014-02-20 {
description
"Released as part of ConfD-5.0.2 / NCS-3.0.2.
-
+
Added tailf:snmp-ned-recreate-when-modified.";
}
revision 2013-12-23 {
description
"Released as part of ConfD-5.0.1 / NCS-3.0.1.
-
+
Allow 'unique' in tailf:annotate and tailf:annotate-statement.
-
+
Added tailf:snmp-ned-delete-before-create.";
}
revision 2013-11-07 {
description
"Released as part of ConfD-5.0 / NCS-3.0.
-
+
Allow tailf:code-name as substatement to 'bit'.
-
+
Disallow tailf:id-value as substatement to 'enum'. Use the
standard YANG 'value' statement instead.
-
+
Deprecated tailf:hex-list. Use yang:hex-string instead.
There are no plans to remove tailf:hex-list.
-
+
Added the types tailf:ipv4-address-and-prefix-length,
tailf:ipv6-address-and-prefix-length, and
tailf:ip-address-and-prefix-length,";
revision 2013-09-05 {
description
"Released as part of ConfD-4.3.
-
+
Added tailf:auto-compact as substatement to tailf:indexed-view.";
}
revision 2013-06-14 {
description
"Released as part of ConfD-4.3.
-
+
Deprecated tailf:symlink. Use tailf:link instead.
-
+
Allow tailf:alt-name as substatement to tailf:action and rpc.
-
+
Allow status as substatement to tailf:action.
-
+
Allow description in tailf:annotate and tailf:annotate-statement.";
}
revision 2013-05-16 {
description
"Released as part of ConfD-4.2.2.
-
+
Added tailf:link";
}
revision 2013-03-07 {
description
"Released as part of ConfD-4.2.
-
+
Allow 'pattern' in tailf:annotate-statement.";
}
revision 2012-11-08 {
description
"Released as part of ConfD-4.1.
-
+
Added tailf:unique-selector and tailf:unique-leaf.
-
+
Allow tailf:info in bit.
-
+
Allow tailf:code-name as substatement to all statements that
define data nodes in the schema tree and the 'rpc',
'notification', 'identity', and 'tailf:action' statements.
-
+
Allow status in tailf:symlink";
}
revision 2012-08-23 {
description
"Released as part of ConfD-4.0.1.
-
+
Allow tailf:cli-operational-mode and tailf:cli-configure-mode in
rpc.";
}
revision 2012-06-14 {
description
"Released as part of ConfD-4.0.
-
+
Added tailf:display-hint.";
}
revision 2012-05-24 {
revision 2012-03-08 {
description
"Released as part of ConfD-3.9.
-
+
Added tailf:timeout.
Added tailf:non-strict-leafref.";
}
revision 2011-12-08 {
description
"Released as part of ConfD-3.8.
-
+
Allow validation statements in tailf:annotate and
tailf:annotate-statement.
-
+
Allow tailf:validate in must, in order to override the evaluation
of the must expression with a callback function.
-
+
Disallow tailf:info in range, length and pattern.
-
+
Added tailf:snmp-ned-* statements to control the SNMP NED
behavior in NCS.";
}
revision 2011-10-20 {
description
"Released as part of ConfD-3.7.1.
-
+
Added tailf:priority.";
}
revision 2011-09-22 {
description
"Released as part of ConfD-3.7.
-
+
Allow tailf:typepoint as substatement to leaf and leaf-list.
Allow tailf:id as substatement to tailf:annotate-module.
Allow tailf:sort-priority as substatement to tailf:symlink.
Added tailf:snmp-delete-value and tailf:snmp-send-delete-value.
Added tailf:step.
Added tailf:annotate-statement.
-
+
Clarified how tailf:display-when is evaluated for lists.";
}
revision 2011-08-25 {
description
"Released as part of ConfD-3.6.2.
-
+
Included latest tailf-cli-extension submodule.";
}
revision 2011-06-30 {
description
"Released as part of ConfD-3.6.1.
-
+
Clarified what statements are allowed in tailf:annotate and
tailf:annotate-module. Specifically, that 'symlink' and 'action'
are not allowed.";
revision 2011-05-26 {
description
"Released as part of ConfD-3.6.
-
+
Allow multiple tailf:snmp-name on leafs that represent MIB scalars.";
}
revision 2011-03-31 {
description
"Released as part of ConfD-3.5.1.
-
+
Allow tailf:alt-name as substatement to tailf:symlink.";
}
revision 2011-02-24 {
description
"Released as part of ConfD-3.5.
-
+
Allow tailf:info as substatement to type.
Added tailf:writable.
Removed the deprecated tailf:cli-default-order statement.
revision 2010-11-04 {
description
"Released as part of ConfD-3.4.
-
+
Added tailf:snmp-exclude-object.
Allow tailf:hidden as substatement to tailf:symlink.
Allow multiple tailf:hidden statements to be specified on a node.
revision 2010-09-16 {
description
"Released as part of ConfD-3.3.2.
-
+
Included latest tailf-cli-extension submodule.";
}
revision 2010-08-19 {
description
"Released as part of ConfD-3.3.1.
-
+
Allow multiple tailf:snmp-name statements, and expanded the
semantic meaning of this statement.";
}
revision 2010-07-21 {
description
"Released as part of ConfD-3.3.0.3.
-
+
Added tailf:sort-priority.";
}
revision 2010-06-17 {
description
"Released as part of ConfD-3.3.
-
+
Added tailf:value-length.
-
+
Added tailf:info-html.
-
+
Added tailf:display-default-order, and deprecated
tailf:cli-default-order.
-
+
Added tailf:dependency as a substatement to when.
-
+
Removed the deprecated statements tailf:constant-leaf and
tailf:constant-value.";
}
revision 2010-04-22 {
description
"Released as part of ConfD-3.2.1.
-
+
Added tailf:invocation-mode,
-
+
Fixed bug in tailf:octet-list pattern.";
}
revision 2010-03-18 {
description
"Released as part of ConfD-3.2.
-
+
Split this module into the main module and two submodules,
tailf-meta-extensions, and tailf-cli-extensions.
-
+
Added many tailf:cli- statements in the submodule
tailf-cli-extensions.
-
+
Added tailf:info.
-
+
Allow tailf:display-when in tailf:action.
-
+
Added tailf:snmp-lax-type-check.
-
+
Deprecated tailf:instance-info-leafs. Use
tailf:cli-instance-info-leafs instead.
-
+
Removed the argument in tailf:cli-show-no to better match
all the other tailf:cli- statements.";
}
revision 2010-01-28 {
description
"Released as part of ConfD-3.1.1.
-
+
Allow tailf:snmp-oid and tailf:snmp-name in tailf:symlink.
-
+
Added tailf:key-default.
-
+
Allow tailf:suppress-echo in leaf and leaf-list.";
}
revision 2009-12-17 {
description
"Released as part of ConfD-3.1.
-
+
Added tailf:dependency as a substatement to must.
-
+
Added must and tailf:display-when as children to tailf:symlink.
-
+
Added tailf:interrupt to tailf:exec.
-
+
Allow many tailf statement as substatements to 'refine'.
-
+
Allow tailf:symlink statement in 'augment' and 'case'.
-
+
Added tailf:internal to tailf:actionpoint.
-
+
Deprecated tailf:constant-leaf and tailf:constant-value.";
}
revision 2009-11-06 {
description
"Released as part of ConfD-3.0.1.
-
+
Added tailf:annotate-module statement.
-
+
Added tailf:code-name statement.
-
+
Clarified the tailf:path-filters statement, and added
tailf:no-subtree-match.";
}
revision 2009-10-01 {
description
"Released as part of ConfD-3.0.
-
+
Clarified that tailf:annotate is applied on the expanded tree.
Bugfixes in some typedef patterns.";
}
revision 2009-03-17 {
description
"Released as part of ConfD-2.8.
-
+
Changed module name from tailf-extensions to reflect the content
better.";
}
The value must start with an S. Any byte magnifier can be left
out, e.g. S1K1B equals 1025 bytes. The order is significant
though, i.e. S1B56G is not a valid byte size.
-
+
In ConfD, a 'size' value is represented as an uint64.";
}
}
description
"A list of dot-separated octets e.g. '192.168.255.1.0'.
-
+
The statement tailf:value-length can be used to restrict the number
of octets. Note that using the 'length' restriction limits the
number of characters in the lexical representation.";
description
"The md5-digest-string type automatically computes a MD5 digest for
a value adhering to this type.
-
+
This is best explained using an example. Suppose we have a
leaf:
-
+
leaf key {
type tailf:md5-digest-string;
}
-
+
A valid configuration is:
-
+
<key>$0$In god we trust.</key>
-
+
The '$0$' prefix signals that this is plain text. When a plain
text value is received by the server, an MD5 digest is
calculated, and the string '$1$<salt>$' is prepended to the
result, where <salt> is a random eight character salt used to
generate the digest. This value is stored in the configuration
data store.
-
+
When a value of this type is read, the computed MD5 value is
always returned. In the example above, the following value
could be returned:
-
+
<key>$1$fB$ndk2z/PIS0S1SvzWLqTJb.</key>
-
+
If a value starting with '$1$' is received, the server
knows that the value already represents an MD5 digest, and
stores it as is in the data store.
-
+
A value adhering to this type must have a '$0$' or a
'$1$<salt>$' prefix.
-
+
If a default value is specified, it must have a '$1$<salt>$' prefix.
-
+
The digest algorithm used is the same as the md5 crypt function
used for encrypting passwords for various UNIX systems, see e.g.
http://www.freebsd.org/cgi/cvsweb.cgi/~checkout/~/src/lib/libcrypt/crypt.c
description
"The sha-256-digest-string type automatically computes a SHA-256
digest for a value adhering to this type.
-
+
A value of this type matches one of the forms:
-
+
$0$<clear text password>
$5$<salt>$<password hash>
$5$rounds=<number>$<salt>$<password hash>
-
+
The '$0$' prefix signals that this is plain text. When a plain
text value is received by the server, a SHA-256 digest is
calculated, and the string '$5$<salt>$' is prepended to the
/confdConfig/cryptHash/rounds parameter, which if set to a number
other than the default will cause '$5$rounds=<number>$<salt>$' to
be prepended instead of only '$5$<salt>$'.
-
+
If a value starting with '$5$' is received, the server
knows that the value already represents a SHA-256 digest, and
stores it as is in the data store.
-
+
If a default value is specified, it must have a '$5$' prefix.
-
+
The digest algorithm used is the same as the SHA-256 crypt function
used for encrypting passwords for various UNIX systems, see e.g.
http://www.akkadia.org/drepper/SHA-crypt.txt";
description
"The sha-512-digest-string type automatically computes a SHA-512
digest for a value adhering to this type.
-
+
A value of this type matches one of the forms:
-
+
$0$<clear text password>
$6$<salt>$<password hash>
$6$rounds=<number>$<salt>$<password hash>
-
+
The '$0$' prefix signals that this is plain text. When a plain
text value is received by the server, a SHA-512 digest is
calculated, and the string '$6$<salt>$' is prepended to the
/confdConfig/cryptHash/rounds parameter, which if set to a number
other than the default will cause '$6$rounds=<number>$<salt>$' to
be prepended instead of only '$6$<salt>$'.
-
+
If a value starting with '$6$' is received, the server
knows that the value already represents a SHA-512 digest, and
stores it as is in the data store.
-
+
If a default value is specified, it must have a '$6$' prefix.
-
+
The digest algorithm used is the same as the SHA-512 crypt function
used for encrypting passwords for various UNIX systems, see e.g.
http://www.akkadia.org/drepper/SHA-crypt.txt";
"The des3-cbc-encrypted-string type automatically encrypts a value
adhering to this type using DES in CBC mode followed by a base64
conversion. If the value isn't encrypted already, that is.
-
+
This is best explained using an example. Suppose we have a leaf:
-
+
leaf enc {
type tailf:des3-cbc-encrypted-string;
}
-
+
A valid configuration is:
-
+
<enc>$0$In god we trust.</enc>
-
+
The '$0$' prefix signals that this is plain text. When a plain
text value is received by the server, the value is DES3/Base64
encrypted, and the string '$3$' is prepended. The resulting
string is stored in the configuration data store.
-
+
When a value of this type is read, the encrypted value is always
returned. In the example above, the following value could be
returned:
-
+
<enc>$3$lyPjszaQq4EVqK7OPOxybQ==</enc>
-
+
If a value starting with '$3$' is received, the server knows
that the value is already encrypted, and stores it as is in the
data store.
-
+
A value adhering to this type must have a '$0$' or a '$3$' prefix.
-
+
ConfD uses a configurable set of encryption keys to encrypt the
string. For details, see 'encryptedStrings' in the
confd.conf(5) manual page.";
tailf:occurence "*";
description
"Makes this data model visible in the northbound interface 'agent'.
-
+
This statement makes it possible to have a data model visible
through some northbound interface but not others. For example,
if a MIB is used to generate a YANG module, the resulting YANG
module can be exposed through SNMP only.
-
+
Use the special agent 'none' to make the data model completely
hidden to all notherbound interfaces.
-
+
The agent can also be a free-form string. In this case, the data
model will be visible to maapi applications using this string as its
'context'.";
Annotation statements can be put in a separate annotation
module, and then passed to 'confdc' (or 'pyang') when the
original module is compiled.
-
+
Any 'tailf' statement, except 'symlink' and 'action' can be
annotated. The statements 'symlink' and 'action' modifies the
data model, and are thus not allowed.
-
+
The validation statements 'must', 'min-elements',
'max-elements', 'mandatory', 'unique', and 'when' can also be
annotated.
-
+
A 'description' can also be annotated.
-
+
'tailf:annotate' can occur on the top-level in a module, or in
another 'tailf:annotate' statement.
-
+
The argument is a 'schema-nodeid', i.e. the same as for
'augment', or a '*'. It identifies a target node in the schema
tree to annotate with new statements. The special value '*' can
be used within another 'tailf:annotate' statetement, to select all
children for annotation.
-
+
The target node is searched for after 'uses' and 'augment'
expansion. All substatements to 'tailf:annotate' are treated as
if they were written inline in the target node, with the
exception of any 'tailf:annotate' substatements. These are
treated recursively. For example, the following snippet adds
one callpoint to /x and one to /x/y:
-
+
tailf:annotate /x {
tailf:callpoint xcp;
tailf:annotate y {
statements can be put in a separate annotation module, and then
passed to 'confdc' (or 'pyang') when the original module is
compiled.
-
+
'tailf:annotate-module' can occur on the top-level in a module,
and is used to add 'tailf' statements to the module statement
itself.
-
+
The argument is a name of the module or submodule to annotate.";
}
touching the module source. Annotation statements can be put in
a separate annotation module, and then passed to 'confdc' (or
'pyang') when the original module is compiled.
-
+
Any 'tailf' statement, except 'symlink' and 'action' can be
annotated. The statements 'symlink' and 'action' modifies the
data model, and are thus not allowed.
-
+
The validation statements 'must', 'min-elements',
'max-elements', 'mandatory', 'unique', and 'when' can also be
annotated.
-
+
The type restriction statement 'pattern' can also be annotated.
-
+
A 'description' can also be annotated.
-
+
The argument is an XPath-like expression that selects a
statement to annotate. The syntax is:
-
+
<statement-name> ( '[' <arg-name> '=' <arg-value> ']' )
-
+
where <statement-name> is the name of the statement to annotate,
and if there are more than one such statement in the parent,
<arg-value> is the quoted value of the statement's argument.
-
+
All substatements to 'tailf:annotate-statement' are treated as
if they were written inline in the target node, with the
exception of any 'tailf:annotate-statement' substatements.
These are treated recursively.
-
+
For example, given the grouping:
-
+
grouping foo {
leaf bar {
type string;
type string;
}
}
-
+
the following snippet adds a callpoint to the leaf 'baz':
-
+
tailf:annotate-statement grouping[name='foo'] {
tailf:annotate-statement leaf[name='baz'] {
tailf:callpoint xcp;
tailf:hex-list
tailf:octet-list
xs:hexBinary
-
+
This type restriction is used to limit the length of the
value-space value of the type. Note that since all these types are
derived from 'string', the standard 'length' statement restricts the
lexical representation of the value.
-
+
The argument is a length expression string, with the same syntax as
for the standard YANG 'length' statement.";
}
tailf:substatement "tailf:no-subtree-match";
description
"Used for type 'instance-identifier' only.
-
+
The argument is a space separated list of absolute or relative XPath
expressions.
-
+
This statement declares that the instance-identifier value must match
one of the specified paths, according to the following rules:
-
+
1. each XPath expression is evaluated, and returns a node set.
-
+
2. if there is no 'tailf:no-subtree-match' statement, the
instance-identifier matches if it refers to a node in this
node set, or if it refers to any descendant node of this
node set.
-
+
3. if there is a 'tailf:no-subtree-match' statement, the
instance-identifier matches if it refers to a node in this
node set.
-
+
For example:
-
+
The value /a/b[key='k1']/c matches the XPath expression
/a/b[key='k1']/c.
-
+
The value /a/b[key='k1']/c matches the XPath expression /a/b/c.
-
+
The value /a/b[key='k1']/c matches the XPath expression /a/b, if
there is no 'tailf:no-subtree-match' statement.
-
+
The value /a/b[key='k1'] matches the XPath expression /a/b, if
there is a 'tailf:no-subtree-match' statement.
";
argument is a positive integer or decimal value greater than
zero. The allowed values for the type is further restricted to
only those values that matches the expression:
-
+
'low' + n * 'step'
-
+
where 'low' is the lowest allowed value in the range, n is a
non-negative integer.
-
+
For example, the following type:
-
+
type int32 {
range '-2 .. 9' {
tailf:step 3;
}
}
-
+
has the value space { -2, 1, 4, 7 }";
}
order for ConfD to be able to manipulate external data, a data
provider registers itself using the callpoint id as described in
confd_lib_dp(3).
-
+
A callpoint is inherited to all child nodes unless another
'callpoint' or an 'cdb-oper' is defined.";
}
transaction. Whenever an element gets written, created, or
deleted, user code gets invoked and can optionally write more
data into the same transaction.
-
+
The difference between set- and transaction hooks are that set
hooks are invoked immediately when an element is modified, but
transaction hooks are invoked at commit time.
-
+
The value 'subtree' means that all nodes in the configuration
below where the hook is defined are affected.
-
+
The value 'object' means that the hook only applies to the list
where it is defined, i.e. it applies to all child nodes that
are not themselves lists.
-
+
The value 'node' means that the hook only applies to
the node where it is defined and none of its children.
-
+
For more details on hooks,
see the 'Transformations, Hooks, Hidden Data and Symlinks'
chapter in the User's Guide.";
transaction. Whenever an element gets written, created, or
deleted, user code gets invoked and can optionally write more
data into the same transaction.
-
+
The difference between set- and transaction hooks are that set
hooks are invoked immediately when an element is modified, but
transaction hooks are invoked at commit time.
-
+
The value 'subtree' means that all nodes in the configuration
below where the hook is defined are affected.
-
+
The value 'object' means that the hook only applies to the list
where it is defined, i.e. it applies to all child nodes that
are not themselves lists.
-
+
The value 'node' means that the hook only applies to
the node where it is defined and none of its children.
-
+
For more details on hooks,
see the 'Transformations, Hooks, Hidden Data and Symlinks'
chapter in the User's Guide.";
"This statement is used when old confspec models are translated to
YANG. It needs to be present if systems deployed with data
based on confspecs are updated to YANG based data models.
-
+
In confspec, the 'id' of a data model was a string that never
would change, even if the namespace URI would change. It is not
needed in YANG, since the namespace URi cannot change as a module
is updated.
-
+
This statement is typically present in YANG modules generated by
cs2yang. If no live upgrade needs to be done from a confspec
based system to a YANG based system, this statement can be
data model. Whenever such a collision occurs the ConfD daemon
fails to start and instructs the developer to use the 'id-value'
statement to resolve the collision.
-
-
+
+
A thorough discussion on id-value can be found in the section Hash
Values and the id-value Statement in the YANG chapter in the User
Guide.";
some other leaf in the datamodel. If no value has been set for
this leaf, it defaults to the value of the leaf that the
'default-ref' argument points to.
-
+
The textual format of a 'default-ref' is an XPath location path with
no predicates.
-
+
The type of the leaf with a 'default-ref' will be set to the
type of the referred leaf. This means that the type statement in
the leaf with the 'default-ref' is ignored, but it SHOULD match the
type of the referred leaf.
-
+
Here is an example, where a group without a 'hold-time' will get as
default the value of another leaf up in the hierarchy:
-
+
leaf hold-time {
mandatory true;
type int32;
not possible to use the function 'find_next' on an
unsorted list. If an unsorted list is filtered (e.g.,
in the CLI, the entire list must be traversed.
-
+
If this value is given for a list stored in CDB, it
has no effect.";
}
system modifies the target data node instead, and whenever the
data node is read, the system returns the value of target data
node.
-
+
Note that if the data node is a leaf, the target node MUST also
be a leaf, and if the data node is a leaf-list, the target node
MUST also be a leaf-list.
-
+
Note that the type of the data node MUST be the same as the
target data node. Currently the compiler cannot check this.
-
+
The argument is an XPath absolute location path. If
the target lies within lists, all keys must be specified.
A key either has a value, or is a reference to a key in the path of the
source node, using the function current() as starting
point for an XPath location path. For example:
-
+
/a/b[k1='paul'][k2=current()/../k]/c";
}
tailf:use-in "leaf-list";
description
"Use for config false leafs and leaf-lists only.
-
+
This extension serves as a hint to the system that the
leaf's type has the implict pattern '[^A-Z]*', i.e., all
strings returned by the data provider are lower case (in
the 7-bit ASCII range).
-
+
The CLI uses this hint when it is run in case-insensitive mode
to optimize the lookup calls towards the data provider.";
}
"This statement creates a secondary index with a given name in the
parent list. The secondary index can be used to control the
displayed sort order of the instances of the list.
-
+
Read more about sort order in 'The ConfD Command-Line Interface
(CLI)' chapters in the User Guide, confd_lib_dp(3), and
confd_lib_maapi(3).
-
+
NOTE: Currently secondary-index is not supported for config false
data stored in CDB.";
}
with C callback functions that is loaded into the ConfD daemon at
startup time. Read more about user-defined types in the
confd_types(3) manual page.
-
+
The argument defines the ID associated with a typepoint. This
ID is provided by the shared object, and used by the ConfD
daemon to locate the implementation of a specific user-defined
"The standard YANG statement 'unique' can be used to check for
uniqueness within a single list only. Specifically, it cannot
be used to check for uniqueness of leafs within a sublist.
-
+
For example:
-
+
container a {
list b {
...
}
}
}
-
+
The unique expression above is not legal. The intention is
that there must not be any two 'server' entries in any 'b' with
the same combination of ip and port. This would be illegal:
-
+
<a>
<b>
<name>b1</name>
</server>
</b>
</a>
-
+
With 'tailf:unique-selector' and 'tailf:unique-leaf', this kind
of constraint can be defined.
-
+
The argument to 'tailf:unique-selector' is an XPath descendant
location path (matches the rule 'descendant-schema-nodeid' in
RFC 6020). The first node in the path MUST be a list node, and
it MUST be defined in the same module as the
tailf:unique-selector. For example, the following is illegal:
-
+
module y {
...
import x {
...
}
}
-
+
For each instance of the node where the selector is defined, it
is evaluated, and for each node selected by the selector, a
tuple is constructed by evaluating the 'tailf:unique-leaf'
expression. All such tuples must be unique. If a
'tailf:unique-leaf' expression refers to a non-existing leaf,
the corresponding tuple is ignored.
-
+
In the example above, the unique expression can be replaced by:
-
+
container a {
tailf:unique-selector 'b/server' {
tailf:unique-leaf 'ip';
...
}
}
-
+
For each container 'a', the XPath expression 'b/server' is
evaluated. For each such server, a 2-tuple is constructed with
the 'ip' and 'port' leafs. Each such 2-tuple is guaranteed to
description
"See 'tailf:unique-selector' for a description of how this statement
is used.
-
+
The argument is an XPath descendant location path (matches the
rule 'descendant-schema-nodeid' in RFC 6020), and it MUST refer to
a leaf.";
typically checks it towards other values in the data store.
Validation callbacks are used when the YANG built-in validation
constructs ('must', 'unique') are not expressive enough.
-
+
Callbacks use the API described in confd_lib_maapi(3) to
access whatever other configuration values needed to perform the
validation.
-
+
Validation callbacks are typically assigned to individual nodes
in the data model, but it may be feasible to use a single
validation callback on a root node. In that case the callback
is responsible for validation of all values and their
relationships throughout the data store.
-
+
The 'validate' statment should in almost all cases have a
'tailf:dependency' substatement. If such a statement is not
given, the validate function is evaluated at every commit,
leading to overall performance degradation.
-
+
If the 'validate' statement is defined in a 'must' statement,
validation callback is called instead of evaluating the must
expression. This is useful if the evaluation of the must statement
or validation function depends on a set of subtrees in the data
store. Whenever a node in one of those subtrees are modified,
the must or when expression is evaluated, or validation code executed.
-
+
The textual format of a 'dependency' is an XPath location path with
no predicates.
-
+
If the node that declares the dependency is a leaf, there is an
implicit dependency to the leaf itself.
-
+
For example, with the leafs below, the validation code for'vp'
will be called whenever 'a' or 'b' is modified.
-
+
leaf a {
type int32;
tailf:validate vp {
leaf b {
type int32;
}
-
+
For 'when' and 'must' expressions, the compiler can derive the
dependencies automatically from the XPath expression in most
cases. The exception is if any wildcards are used in the expression.
-
+
For 'when' expressions to work, a 'tailf:dependency' statement
must be given, unless the compiler can figure out the dependency
by itself.
-
+
Note that having 'must' expressions or a 'tailf:validate'
statement without dependencies impacts the overall performance
of the system, since all such 'must' expressions or validation
"This extension takes an integer parameter specifying the order
validation code will be evaluated, in order of increasing
priority.
-
+
The default priority is 0.";
}
description
"Contains a textual description of the definition, suitable for
being presented to the CLI and WebUI users.
-
+
The first sentence of this textual description is used in the
CLI as a summary, and displayed to the user when a short
explanation is presented.
-
+
The 'description' statement is related, but targeted to the module
reader, rather than the CLI or WebUI user.
-
+
The info string may contain a ';;' keyword. It is used in type
descriptions for leafs when the builtin type info needs to be
customized. A 'normal' info string describing a type is assumed
before displaying the string to the user. In most cases,
using this statement avoids using special descriptions in webspecs
and clispecs.
-
+
If this statement is present, 'tailf:info' cannot be given at the same
time.";
}
can be placed on leafs, containers, lists and leaf-lists.
When showing, or getting configuration, leaf values will be returned
in order of increasing sort-priority.
-
+
The default sort-priority is 0.";
}
northbound interfaces. All nodes with the same value are
considered a hide group and are treated the same with regards to
being visible or not in a northbound interface.
-
+
A node with an hidden property is not shown in the northbound
user interfaces (CLI and Web UI) unless an 'unhide' operation has
been performed in the user interface.
-
+
The hidden value 'full' indicates that the node should be hidden
from all northbound interfaces, including programmatical interfaces
such as NETCONF.
-
+
The value '*' is not valid.
-
+
A hide group can be unhidden only if this has been explicitly
allowed in the confd.conf(5) daemon configuration.
-
+
Multiple hide groups can be specified by giving this statement
multiple times. The node is shown if any of the specified hide groups
has been given in the 'unhide' operation.
-
+
Note that if a mandatory node is hidden, a hook callback
function (or similar) might be needed in order to set the
element.";
evaluated by the CLI. If the XPath expression evaluates to
true, the node is shown as a possible completion candidate,
otherwise not.
-
+
For a list, the display-when expression is evaluated once for the
entire list. In this case, the XPath context node is the list's parent
node.
-
+
This feature is further described in the 'Transformations, Hooks,
Hidden Data and Symlinks' chapter in the User Guide.";
}
"This property is used in the CLI when 'enableDisplayGroups' has been
set to true in the confd.conf(5) file. Display groups are used
to control which elements should be displayed by the show command.
-
+
The argument is a space-separated string of tags.
-
+
In the J-style CLI the 'show status', 'show table' and 'show
all' commands use display groups. In the C- and I-style
CLIs the 'show <pattern>' command uses display groups.
-
+
If no display groups are specified when running the commands, the
node will be displayed if it does not have the 'display-groups'
property, or if the property value includes the special value 'none'.
-
+
If display groups are specified when running the command, then
the node will be displayed only if its 'display-group'
property contains one of the specified display groups.";
description
"Specifies that the list should be displayed sorted according
to this secondary index in the show command.
-
+
If the list has more than one secondary index,
'display-default-order' must be present in one index only.
-
+
Used in J-, I- and C-style CLIs and WebUI.";
}
typedef of type binary. The display-hint is used in the CLI
and WebUI instead of displaying the binary as a base64-encoded
string. It is also used for input.
-
+
The value of a 'display-hint' is defined in RFC 2579.
-
+
For example, with the display-hint value '1x:', the value is
printed and inputted as a colon-separated hex list.";
}
tailf:use-in "refine";
description
"Used when the YANG module is mapped to an SNMP module.
-
+
If this statement is present as a direct child to 'module',
it indicates the top level OID for the module.
-
+
When the parent node is mapped to an SNMP object, this statement
specifies the OID of the SNMP object. It may be either a full
OID or just a suffix (a period, followed by an integer). In the
latter case, a full OID must be given for some ancestor element.
-
+
NOTE: when this statement is set in a list, it refers to the OID of
the correspondig table, not the table entry.";
}
tailf:occurence "*";
description
"Used when the YANG module is mapped to an SNMP module.
-
+
When the parent node is mapped to an SNMP object, this statement
specifies the name of the SNMP object.
-
+
If the parent node is mapped to multiple SNMP objects, this
statement can be given multiple times. The first statement
specifies the primary table.
-
+
In a list, the argument is interpreted as:
-
+
[MIB-MODULE-NAME:]TABLE-NAME
-
+
For a leaf representing a table column, it is interpreted as:
-
+
[[MIB-MODULE-NAME:]TABLE-NAME:]NAME
-
+
For a leaf representing a scalar variable, it is interpreted as:
-
+
[MIB-MODULE-NAME:]NAME
-
+
If a YANG list is mapped to multiple SNMP tables, each such SNMP
table must be specified with a 'tailf:snmp-name' statement. If
the table is defined in another MIB than the MIB specified in
'tailf:snmp-mib-module-name', the MIB name must be specified in this
argument.
-
+
A leaf in a list that is mapped to multiple SNMP tables must specify
the name of the table it is mapped to if it is different from the
primary table.
-
+
In the following example, a single YANG list 'interface' is mapped
to the MIB tables ifTable, ifXTable, and ipv4InterfaceTable:
-
+
list interface {
key index;
tailf:snmp-name 'ifTable'; // primary table
tailf:snmp-name 'ifXTable';
tailf:snmp-name 'IP-MIB:ipv4InterfaceTable';
-
+
leaf index {
type int32;
}
}
...
}
-
+
When emitting a mib from yang, enum labels are used as-is if they
follow the SMI rules for labels (no '.' or '_' characters and beginning
with a lowercase letter). Any label that doesn't satisfy the SMI rules
will be converted as follows:
-
+
An initial uppercase character will be downcased.
-
+
If the initial character is not a letter it will be prepended with
an 'a'.
-
+
Any '.' or '_' characters elsewhere in the label will be substituted
with '-' characters.
-
+
In the resulting label, any multiple '-' character sequence will be
replaced with a single '-' character.
-
+
If this automatic conversion is not suitable, snmp-name can be used
to specify the label to use when emitting a MIB.";
}
tailf:use-in "refine";
description
"Used when the YANG module is mapped to an SNMP module.
-
+
Specifies the name of the SNMP MIB module where the SNMP objects
are defined.
-
+
This property is inherited by all child nodes.";
}
tailf:use-in "refine";
description
"Used when an SNMP module is generated from the YANG module.
-
+
When the parent list node is mapped to an SNMP table, this
statement specifies the column number of the generated RowStatus
column. If it is not specified, the generated RowStatus column
snmp-lax-type-check is set to 'true', the compiler accepts the
object if the SNMP type's value space is a superset of the YANG
type's value space.
-
+
If snmp-lax-type-check is true and the MIB object is writable, the SNMP
agent will reject values outside the YANG data type range in runtime.";
}
description
"Used when an SNMP MIB is generated from a YANG module, using
the --generate-oids option to confdc.
-
+
If this statement is present, confdc will exclude this object
from the resulting MIB.";
}
to delete an optional leaf. The argument to this statement is the
special value. This special value must not be part of the value
space for the YANG leaf.
-
+
If the optional leaf does not exists, reading it over SNMP returns
'noSuchInstance', unless the statement 'tailf:snmp-send-delete-value'
is used, in which case the same value as used to delete the node
is returned.
-
+
For example, the YANG leaf:
-
+
leaf opt-int {
type int32 {
range '1..255';
tailf:snmp-send-delete-value;
}
}
-
+
can be mapped to a SMI object with syntax:
-
+
SYNTAX Integer32 (0..255)
-
+
Setting such an object to '0' over SNMP will delete the node
from the datastore. If the node does not exsist, reading it over
SNMP will return '0'.";
"This statement is used on all columns in a table that
require the usage of the column marked with
tailf:snmp-ned-set-before-row-modification.
-
+
This statement can be used on any column in a table where one
leaf is marked with tailf:snmp-ned-set-before-row-modification,
or a table that AUGMENTS such a table, or a table with a
not have to be writable. The SNMP NED will use this column
when it uses GET-NEXT to loop through the list entries, and
when doing existence tests.
-
+
If this column is not given, the SNMP NED uses the following
algorithm:
-
+
1. If there is a RowStatus column, it will be used.
2. If an INDEX leaf is accessible, it will be used.
3. Otherwise, use the first accessible column returned
tailf:substatement "tailf:info-html";
description
"Defines an action (method) in the data model.
-
+
When the action is invoked, the instance on which the action is
invoked is explicitly identified by an hierarchy of
configuration or state data.
-
+
The action statement can have either a 'tailf:actionpoint' or a
'tailf:exec' substatement. If the action is implemented as a
callback in an application daemon, 'tailf:actionpoint' is used,
standalone executable (program or script). Additionally, 'action'
can have the same substatements as the standard YANG 'rpc'
statement, e.g., 'description', 'input', and 'output'.
-
+
For example:
-
+
container sys {
list interface {
key name;
}
}
}
-
+
We can also add a 'tailf:confirm-text', which defines a string to
be used in the user interfaces to prompt the user for
confirmation before the action is executed. The optional
'tailf:confirm-default' and 'tailf:cli-batch-confirm-default' can be set
to control if the default is to proceed or to abort. The latter will only
be used during batch processing in the CLI (e.g. non-interactive mode).
-
+
tailf:action reset {
tailf:actionpoint my-ap;
input {
tailf:confirm-default true;
}
}
-
+
The 'tailf:actionpoint' statement can have a 'tailf:opaque'
substatement, to define an opaque string that is passed to the
callback function.
-
+
tailf:action reset {
tailf:actionpoint my-ap {
tailf:opaque 'reset-interface';
}
}
}
-
+
When we use the 'tailf:exec' substatement, the argument to exec
specifies the program or script that should be executed. For
example:
-
+
tailf:action reboot {
tailf:exec '/opt/sys/reboot.sh' {
tailf:args '-c $(context) -p $(path)';
description
"This element can only be used if the list has a single key of
an integer type.
-
+
It is used to signal that lists instances uses an indexed view,
i.e., making it possible to insert a new list entry at a certain
position. If a list entry is inserted at a certain position, list
entries following this position are automatically renumbered by the
system, if needed, to make room for the new entry.
-
+
This statement is mainly provided for backwards compatibility with
confspecs. New data models should consider using YANG's ordered-by
user statement instead.";
can either be insterted anywhere in the list, or created at the
end; but it is an error to try to create a list entry with a
key that would result in a hole in the sequence.
-
+
For example, if the list has entries 1,2,3 it is an error to
create entry 5, but correct to create 4.";
}
tailf:use-in "leaf";
description
"Must be used for key leafs only.
-
+
Specifies a value that the CLI and WebUI will use when a list entry is
created, and this key leaf is not given a value.
-
+
If one key leaf has a key-default value, all key leafs that
follow this key leaf must also have key-default values.";
}
description
"Declares a set of data nodes to be used in the NETCONF <error-info>
element.
-
+
A data provider can use one of the
confd_*_seterr_extended_info() functions (see confd_lib_dp(3))
to set these data nodes on errors.
-
+
This statement may be used multiple times.
-
+
For example:
-
+
tailf:error-info {
leaf severity {
type enumeration {
"This statement can be used in leafs and leaf-lists similar
to 'leafref', but allows reference to non-existing leafs,
and allows reference from config to non-config.
-
+
This statement takes no argument, but expects the core YANG
statement 'path' as a substatement. The function 'deref' cannot
be used in the path, since it works on nodes of type leafref
only.
-
+
The type of the leaf or leaf-list must be exactly the same
as the type of the target.
-
+
This statement can be viewed as a substitute for a standard
'require-instance false' on leafrefs, which isn't allowed.
-
+
The CLI uses this statement to provide completion with
existing values, and the WebUI uses it to provide a
drop-down box with existing values.";
argument strings. It may contain variables on the form
$(variablename). These variables will be expanded before the
command is executed. The following variables are always available:
-
+
$(user) The name of the user which runs the operation.
-
+
$(groups) A comma separated string of the names of the groups
the user belongs to.
-
+
$(ip) The source ip address of the user session.
-
+
$(uid) The user id of the user.
-
+
$(gid) The group id of the user.
-
+
When the parent 'exec' statement is a substatement of 'action', the
following additional variablenames are available:
-
+
$(keypath) The path that identifies the parent container of 'action'
in string keypath form, e.g.,
'/sys:host{earth}/interface{eth0}'.
-
+
$(path) The path that identifies the parent container of 'action'
in CLI path form, e.g., 'host earth interface eth0'.
-
+
$(context) cli | webui | netconf | any string provided by MAAPI
-
+
For example:
args '-user $(user) $(uid)';
might expand to:
"Specifies that ConfD should not convert the RPC XML parameters to
command line arguments. Instead, ConfD just passes the raw XML on
stdin to the program.
-
+
This statement is not allowed in 'tailf:action'.";
}
description
"This statement specifies which signal is sent to executable by ConfD
in case the client terminates or aborts the execution.
-
+
If not specified, 'sigkill' is sent.";
}
tailf:use-in "tailf:exec";
description
"Specifies which user id to use when executing the command.
-
+
If 'uid' is an integer value, the command is run as the user with
this user id.
-
+
If 'uid' is set to either 'user', 'root' or an integer user id, the
ConfD daemon must have been started as root (or setuid), or the
ConfD executable program 'cmdwrapper' must have setuid root
tailf:use-in "tailf:exec";
description
"Specifies which group id to use when executing the command.
-
+
If 'gid' is an integer value, the command is run as the group with
this group id.
-
+
If 'gid' is set to either 'user', 'root' or an integer group id, the
ConfD daemon must have been started as root (or setuid), or the
ConfD executable program 'cmdwrapper' must have setuid root
description
"DEPRECATED: Use yang:hex-string instead. There are no plans to remove
tailf:hex-list.
-
+
A list of colon-separated hexa-decimal octets e.g. '4F:4C:41:71'.
-
+
The statement tailf:value-length can be used to restrict the number
of octets. Note that using the 'length' restriction limits the
number of characters in the lexical representation.";
description
"DEPRECATED: Use tailf:link instead. There are no plans to remove
tailf:symlink.
-
+
This statement defines a 'symbolic link' from a node to some other node.
The argument is the name of the new node, and the mandatory substatement
'tailf:path' points to the node which is linked to.";
tailf:use-in "tailf:symlink";
description
"This statement specifies which node a symlink points to.
-
+
The textual format of a symlink is an XPath absolute location path. If
the target lies within lists, all keys must be specified.
A key either has a value, or is a reference to a key in the path of the
source node, using the function current() as starting
point for an XPath location path. For example:
-
+
/a/b[k1='paul'][k2=current()/../k]/c
";
}
Code Review / integration / test.git / blobdiff