Typedefs

Specifies a value that can be translated to the numeric value
of the traffic class to be used as either the congesting or
monitored queue. The absolute value of the enumerated value is
the value of the taffic class plus 1. A value of 0 indicates the
traffic class is not participating in congestion isolation. For
example, the enumerated value congesting-queue-tc-5 specifies
that traffic class 4 is used as the congesting queue.

NETCONF Access Operation.

Access operation.

This type is used by data models that
need to referenced an acl

This type is used to refer to an Access Control List
(ACL) type

This type is used to refer to an ACL type.

The scope of the action.

Action taken by the server when a particular
rule matches.

Action taken by the server when a particular
rule matches.

Definition for action type.

Type of notification on software or database activation events

Indicates the activation type of an ACL.

active-type

This type defines ISIS adaptive timer types

Target address attribute type.

Target address attribute type.

Defines a type for the address family.

Defines a type for the address family.

Enumeration containing all the IANA-defined
Address Families.

Enumeration containing all the IANA-defined
Address Families.

Defines a type for the address family.

RIB address family definition.

Address pool type.

This type represents an address object or an address group name.

Derived types for TE administrative groups.

Represents the various possible administrative states.

Represents the various possible administrative states.

Admin state of the OAM function on an interface.

Administrative state modes for
logical channels in the transponder model.

Represents SnmpAdminString as defined in RFC 3411.

Note that the size of an SnmpAdminString is measured in
octets, not characters.

The aggregate maximum downlink bit rate that is
requested/allocated for downlink IP flows.  The measurement
units are bits per second.

The aggregate maximum downlink bit rate that is
requested/allocated for downlink IP flows.  The measurement
units are bits per second.

Type to define the lag-type, i.e., how the LAG is
defined and managed

ais-interval

Represents the possible values of alarm states.  An alarm is a
persistent indication of an error or warning condition.

When no bits of this attribute are set, then no active alarms
are known against this component and it is not under repair.

Represents the possible values of alarm states.  An alarm is a
persistent indication of an error or warning condition.

When no bits of this attribute are set, then no active alarms
are known against this component and it is not under repair.

The string used to inform operators about the alarm.  This
MUST contain enough information for an operator to be able to
understand the problem and how to resolve it.  If this string
contains structure, this format should be clearly documented
for programs to be able to parse that information.

Identifies an alarm type.  The description of the alarm type
id MUST indicate whether or not the alarm type is abstract.
An abstract alarm type is used as a base for other alarm type
ids and will not be used as a value for an alarm or be present
in the alarm inventory.

If an alarm type cannot be fully specified at design time by
'alarm-type-id', this string qualifier is used in addition to
fully define a unique alarm type.

The definition of alarm qualifiers is considered to be part of
the instrumentation and is out of scope for this module.  An
empty string is used when this is part of a key.

connection direction type

demand group operation type

demand type

endpoint group type

endpoint type

Defines the alternate name search mode that
should be used when resolving YANG node names
in leafs or leaflists using the UrlPath data type.

If 'true' then nodes with an 'alt-name' defined
will be considered a match if the YANG name or the
alternative name matches the search string.

If 'false' then only the YANG node name will
be used in node name searches.

Operational mode for the amplifier:
this parameter allows modeling different operational modes (gain ranges) ,notably for switched-gain amplifiers.
It indicates which performance model shall be used by the path feasibility engine.
For standard amplifier, or when performance evaluation is based on incremental noise, use gain-range-1.
When performance evaluation is based on advanced parameters, specify used gain-range (1 to 4).
Up to release 2.1, only gain-range-1 is to be used (default value) 

identifier for amplifier type
1. standard for amplifier as defined initially in the ROADM MSA specifications
To be completed if/when additional amplifier types are required 

The angle in degress.

XSD universal resource identifier string type.

This type defines the ISIS area address.

Area ID type.

A numeric identifier for an autonomous system (AS). An AS is a
single domain, under common administrative control, which forms
a unit of routing policy. Autonomous systems can be assigned a
2-byte identifier, or a 4-byte identifier which may have public
or private scope. Private ASNs are assigned from dedicated
ranges. Public ASNs are assigned from ranges allocated by IANA
to the regional internet registries (RIRs).

The as-number type represents autonomous system numbers
which identify an Autonomous System (AS).  An AS is a set
of routers under a single technical administration, using
an interior gateway protocol and common metrics to route
packets within the AS, and using an exterior gateway
protocol to route packets to other ASs'.  IANA maintains
the AS number space and has delegated large parts to the
regional registries.

Autonomous system numbers were originally limited to 16
bits.  BGP extensions have enlarged the autonomous system
number space to 32 bits.  This type therefore uses an uint32
base type without a range restriction in order to support
a larger autonomous system number space.

In the value set and its semantics, this type is equivalent
to the InetAutonomousSystemNumber textual convention of
the SMIv2.

The as-number type represents autonomous system numbers
which identify an Autonomous System (AS).  An AS is a set
of routers under a single technical administration, using
an interior gateway protocol and common metrics to route
packets within the AS, and using an exterior gateway
protocol to route packets to other ASes.  IANA maintains
the AS number space and has delegated large parts to the
regional registries.

Autonomous system numbers were originally limited to 16
bits.  BGP extensions have enlarged the autonomous system
number space to 32 bits.  This type therefore uses an uint32
base type without a range restriction in order to support
a larger autonomous system number space.

In the value set and its semantics, this type is equivalent
to the InetAutonomousSystemNumber textual convention of
the SMIv2.

A numeric identifier for an autonomous system (AS). An AS is a
single domain, under common administrative control, which forms
a unit of routing policy. Autonomous systems can be assigned a
2-byte identifier, or a 4-byte identifier which may have public
or private scope. Private ASNs are assigned from dedicated
ranges. Public ASNs are assigned from ranges allocated by IANA
to the regional internet registries (RIRs).

Defines the types of BGP AS path segments.

This typedef enables modules to easily define a reference
to an asymmetric key stored in the Keystore.

Enumeration for attack status codes.

Method for authenticating an ONU.

TRILL authentication mode.

A Controller may have multiple auxiliary connections as
specified by the Openflow protocol. The main Controller
connection should always have the auxiliary-id set to zero.
All other connections must have an auxiliary-id different
from 0.

A set of availability status conditions.  An empty set of
bits implies that none of the status conditions are
present, i.e., the entity is available.

Represents the available upstream and downstream bands.

Valid bandplan definitions.

Bandwidth of the port.

Bandwidth in bits per second of a communcation channel.

Bandwidth of the port.

Bandwidth values, expressed in gigabits per second.

Bandwidth values expressed in gigabits per second

Bandwidth in IEEE 754 floating point 32-bit binary format:
(-1)**(S) * 2**(Exponent-127) * (1 + Fraction),
where Exponent uses 8 bits, and Fraction uses 23 bits.
The units are octets per second.
The encoding format is the external hexadecimal-significant
character sequences specified in IEEE 754 and C99. The
format is restricted to be normalized, non-negative, and
non-fraction: 0x1.hhhhhhp{+}d, 0X1.HHHHHHP{+}D, or 0x0p0,
where 'h' and 'H' are hexadecimal digits and'd' and 'D' are
integers in the range of [0..127].
When six hexadecimal digits are used for 'hhhhhh' or
'HHHHHH', the least significant digit must be an even
number. 'x' and 'X' indicate hexadecimal; 'p' and 'P'
indicate power of two. Some examples are: 0x0p0, 0x1p10, and
0x1.abcde2p+20

Bandwidth in IEEE 754 floating point 32-bit binary format:
(-1)**(S) * 2**(Exponent-127) * (1 + Fraction),
where Exponent uses 8 bits, and Fraction uses 23 bits.
The units are octets per second.
The encoding format is the external hexadecimal-significand
character sequences specified in IEEE 754 and C99,
restricted to be normalized, non-negative, and non-fraction:
0x1.hhhhhhp{+}d or 0X1.HHHHHHP{+}D
where 'h' and 'H' are hexadecimal digits, 'd' and 'D' are
integers in the range of [0..127].
When six hexadecimal digits are used for 'hhhhhh' or 'HHHHHH',
the least significant digit must be an even number.
'x' and 'X' indicate hexadecimal; 'p' and 'P' indicate power
of two.
Some examples are: 0x0p0, 0x1p10, and 0x1.abcde2p+20

Bandwidth in IEEE 754 floating-point 32-bit binary format:
(-1)**(S) * 2**(Exponent-127) * (1 + Fraction),
where Exponent uses 8 bits and Fraction uses 23 bits.
The units are octets per second.
The encoding format is the external hexadecimal-significant
character sequences specified in IEEE 754 and ISO/IEC C99.
The format is restricted to be normalized, non-negative, and
non-fraction: 0x1.hhhhhhp{+}d, 0X1.HHHHHHP{+}D, or 0x0p0,
where 'h' and 'H' are hexadecimal digits and 'd' and 'D' are
integers in the range of [0..127].
When six hexadecimal digits are used for 'hhhhhh' or
'HHHHHH', the least significant digit must be an even
number.  'x' and 'X' indicate hexadecimal; 'p' and 'P'
indicate a power of two.  Some examples are 0x0p0, 0x1p10,
and 0x1.abcde2p+20.

Bandwidth values, expressed in kilobits per second.

Bandwidth values expressed in kilobits per second

Bandwidth values, expressed in megabits per second.

Bandwidth values expressed in megabits per second

Reusable type for by-name reference to a base interface.
This type may be used in cases where ability to reference
a subinterface is not required.

XSD base64 binary encoded string

Diffserv-TE bandwidth constraints as defined in RFC 4124.

Option for the BGP as-prepend policy action.  Prepends the
local AS number repeated n times

A type definition utilised to define the extended community
in a context where the system is receiving the extended
community from an external source, such that the value may be
unknown. In the case that the received extended community is
unknown it is defined to be a 8-octet quantity formatted
according to RFC4360:

Type Field: 1 or 2 octets.
Value Field: Remaining octets.

The high-order octet of the type field is encoded such that
bit 0 indicates whether the extended community type is IANA
assigned; and bit 1 indicates whether the extended community
is transitive.  The remaining bits of the high-order type
field must be interpreted to determine whether the low-order
type field should be parsed, or whether the entire remainder
of the extended community is a value.

Type definition for extended community attributes. In the case that
common communities are utilised, they are represented as a string
of the form:
 - <2b AS>:<4b value> per RFC4360 section 3.1
 - <4b IPv4>:<2b value> per RFC4360 section 3.2
 - <4b AS>:<2b value> per RFC5668 section 2.
 - route-target:<2b AS>:<4b value> per RFC4360 section 4
 - route-target:<4b IPv4>:<2b value> per RFC4360 section 4
 - route-origin:<2b ASN>:<4b value> per RFC4360 section 5
 - route-origin:<4b IPv4>:<2b value> per RFC4360 section 5
 - color:<CO bits>:<4b value> per draft-ietf-idr-segment-routing-te-policy
   section 3

type definition for specifying next-hop in policy actions

Type definition for standard BGP origin attribute

Enumeration for BGP SAFI.

Enumeration for BGP SAFI.

Type to describe the direction of NLRI transmission

Type definition for options when setting the community
attribute in a policy action

Type definition for specifying how the BGP MED can
be set in BGP policy actions. The three choices are to set
the MED directly, increment/decrement using +/- notation,
and setting it to the IGP cost (predefined value).

Type definition for standard commmunity attributes represented as
a integer value, or a string of the form N:M where N and M are
integers between 0 and 65535.

Type definition for well-known IETF community attribute
values

A binary type where each octet represents data belonging to
a sub-carrier group. The first octet represents sub-carrier
group 0.

Unique Bridge Identifier

An integer that uniquely identifies a Bridge Port.

This type is used by data models that need to reference
a configured Bridge.

The type defined for the broadband line characteristics
listed in TR-101i2.

Burst size in bytes.

XSD 8 bit signed integer.

The value rang for cv packet detect multiplier

The value rang for cc packet transmit and receive
interval.

CC session mode

Indicates the interval at which CCM PDUs are sent by a MEP.

A 3 bit priority value to be used in the VLAN tag,
if present in the transmitted frame.

A 3 bits priority value to be used in the VLAN tag,
if present in the transmitted frame.

A 3-bit priority value to be used in the VLAN tag,
if present in the transmitted frame.

A period of time, measured in units of 0.01 seconds.

The certificate id must starts with a letter and
end with a letter or digit. Interior characters are only
alphabets, digits, minus, underscore and dot.

Specifies different types of datastore changes.

This type is based on the edit operations defined for
YANG Patch, with the difference that it is valid for a
receiver to process an update record that performs a
'create' operation on a datastore node the receiver believes
exists or to process a delete on a datastore node the
receiver believes is missing.

Used to reference a channel estimation profile.

xDSL Transceiver Unit (xTU) Channel Threshold Profile name.

Type to specify all the WiFi channels available for use. This is
a superset of what may be allowed by any one particular regulatory
domain.

The source of a chassis identifier.

The source of a chassis identifier.

Type definition with enumerations describing the source of
the chassis identifier

The format of a chassis identifier string. Objects of this type
are always used with an associated lldp-chassis-is-subtype
object, which identifies the format of the particular
lldp-chassis-id object instance.

If the associated lldp-chassis-id-subtype object has a value of
chassis-component, then the octet string identifies
a particular instance of the entPhysicalAlias object
(defined in IETF RFC 2737) for a chassis component (i.e.,
an entPhysicalClass value of chassis(3)).

If the associated lldp-chassis-id-subtype object has a value
of interface-alias, then the octet string identifies
a particular instance of the ifAlias object (defined in
IETF RFC 2863) for an interface on the containing chassis.
If the particular ifAlias object does not contain any values,
another chassis identifier type should be used.

If the associated lldp-chassis-id-subtype object has a value
of port-component, then the octet string identifies a
particular instance of the entPhysicalAlias object (defined
in IETF RFC 2737) for a port or backplane component within
the containing chassis.

If the associated lldp-chassis-id-subtype object has a value of
mac-address, then this string identifies a particular
unicast source address (encoded in network byte order and
IEEE 802.3 canonical bit order), of a port on the containing
chassis as defined in IEEE Std 802-2001.

If the associated lldp-chassis-id-subtype object has a value of
network-address, then this string identifies a particular
network address, encoded in network byte order, associated
with one or more ports on the containing chassis.  The first
octet contains the IANA Address Family Numbers enumeration
value for the specific address type, and octets 2 through
N contain the network address value in network byte order.

If the associated lldp-chassis-id-subtype object has a value
of interface-name, then the octet string identifies
a particular instance of the ifName object (defined in
IETF RFC 2863) for an interface on the containing chassis.
If the particular ifName object does not contain any values,
another chassis identifier type should be used.

If the associated lldp-chassis-id-subtype object has a value of
local, then this string identifies a locally assigned
Chassis ID.

The format of a chassis identifier string. Objects of this type
are always used with an associated lldp-chassis-is-subtype
object, which identifies the format of the particular
lldp-chassis-id object instance.

If the associated lldp-chassis-id-subtype object has a value of
chassis-component, then the octet string identifies
a particular instance of the entPhysicalAlias object
(defined in IETF RFC 2737) for a chassis component (i.e.,
an entPhysicalClass value of chassis(3)).

If the associated lldp-chassis-id-subtype object has a value
of interface-alias, then the octet string identifies
a particular instance of the ifAlias object (defined in
IETF RFC 2863) for an interface on the containing chassis.
If the particular ifAlias object does not contain any values,
another chassis identifier type should be used.

If the associated lldp-chassis-id-subtype object has a value
of port-component, then the octet string identifies a
particular instance of the entPhysicalAlias object (defined
in IETF RFC 2737) for a port or backplane component within
the containing chassis.

If the associated lldp-chassis-id-subtype object has a value of
mac-address, then this string identifies a particular
unicast source address (encoded in network byte order and
IEEE 802.3 canonical bit order), of a port on the containing
chassis as defined in IEEE Std 802-2001.

If the associated lldp-chassis-id-subtype object has a value of
network-address, then this string identifies a particular
network address, encoded in network byte order, associated
with one or more ports on the containing chassis.  The first
octet contains the IANA Address Family Numbers enumeration
value for the specific address type, and octets 2 through
N contain the network address value in network byte order.

If the associated lldp-chassis-id-subtype object has a value
of interface-name, then the octet string identifies
a particular instance of the ifName object (defined in
IETF RFC 2863) for an interface on the containing chassis.
If the particular ifName object does not contain any values,
another chassis identifier type should be used.

If the associated lldp-chassis-id-subtype object has a value of
local, then this string identifies a locally assigned
Chassis ID.

Identifies a child node string for use in the
YANG mapping. There are two allowed formats:

module-name:child-name -- used only for a child node
from a different module namespace than the parent node.

child-name -- used only for a child node from the
same module namespace as the parent node.

This type defines ISIS interface types 

One CLASSMASK parameter is defined per the G.993.2 Annex
enabled in the xDSL Transmission System Enabling (XTSE). It
selects a single Power Spectral Density (PSD) mask class
per the G.993.2 Annex that is activated at the VTU-O.
The coding is as indicated in Table 7-6 of [ITU-T G.997.1].

The client status. RPF, LPF and OK are defined.

Add 'none' to standard enumerations

Derived data type to identify a clock

Derived data type to identify a clock

Derived data type to identify a clock

Derived data type to identify a clock

Represents an IEEE 802.1 MAC address represented in the
'canonical' order defined by IEEE 802.1a, EUI-64. EUI-48
converts to EUI-64 as specified by IEEE. The conversion
assigns values 255 and 254 to octets 3 and 4, respectively,
where octet 0 is the most significant and octet 7 the least.
For example, EUI-48 of AC:DE:48:23:45:67 would extend to
AC:DE:48:FF:FE:23:45:67.

A CMS structure, as specified in RFC 5652, encoded using
ASN.1 distinguished encoding rules (DER), as specified in
ITU-T X.690.

A ContentInfo structure, as specified in RFC 5652,
encoded using ASN.1 distinguished encoding rules (DER),
as specified in ITU-T X.690.

The Color Mode (CM) indicates the type of color awareness which
is employed by the Policer.

type describing variations of community attributes:
STANDARD: standard BGP community [rfc1997]
EXTENDED: extended BGP community [rfc4360]
BOTH: both standard and extended community

The range of valid values for the 3-element complex
conductances and susceptances, GTR and BTR (Tip-to-Ring);
GTG and BTG (Tip-to-Ground); and GRG and BRG (Ring-to-Ground)
is from 0.1 uSiemens to 0.1 Siemens. The values shall be
represented in linear format with a granularity of 0.1
uSiemens.

NOTE - The linear format is chosen for simplicity reason and
does not imply any future accuracy requirements.

Definition for component type.

A generic type reflecting whether a hardware component
is powered on or off

A composite type strictly meant for leaves reflecting the
already allocated downstream or upstream channel-id on a
channel-group.
Such leaves are used to prevent conflicts when allocating
a channel-pair to a channel-group. For NG-PON2, the applicable
values are in [0..7], for XGS-PON a dedicated value 'xgs'
is used rather than '0' to prevent ambiguity between this and
the valid value '0' for NG-PON2.

A composite type strictly meant for leaves reflecting the
already allocated downstream or upstream channel-id on a
channel-group.
Such leaves are used to prevent conflicts when allocating a
channel-pair to a channel-group. For NG-PON2, the applicable
values are in [0..8], for XGS-PON a dedicated value 'xgs'
is applicable rather than value '0': this is not to a priori
forbid in yang model the coexistence of XGS-PON with NG-PON2
using channel-id=0.

The confidentiality offset specifies a number of octets in an Ethernet
frame that are sent in unencrypted plain-text

Specifies how edits will be applied in config mode.

While making the MIP creation evaluation described in
22.2.3, the management entity can encounter errors in
the configuration.

NETCONF 'confirm-timeout' Element Content

Enumeration for conflict causes.

Nickname conflict state.

Enumeration for conflict status.

This type is used by data models that need to reference
configured context metadata headers.

Defining a type of the control mode on L2CP protocols.

Defining a type of the control mode on L2CP protocols.

Defines the type of control mode on L2CP protocols.

The position along a single coordinate.

A 32-bit counter. A counter value is a monotonically increasing
value which is used to express a count of a number of
occurrences of a particular event or entity. When the counter
reaches its maximum value, in this case 2^32-1, it wraps to 0.

Discontinuities in the counter are generally triggered only when
the counter is reset to zero.

The counter32 type represents a non-negative integer
that monotonically increases until it reaches a
maximum value of 2^32-1 (4294967295 decimal), when it
wraps around and starts increasing again from zero.

Counters have no defined 'initial' value, and thus, a
single value of a counter has (in general) no information
content.  Discontinuities in the monotonically increasing
value normally occur at re-initialization of the
management system, and at other times as specified in the
description of a schema node using this type.  If such
other times can occur, for example, the creation of
a schema node of type counter32 at times other than
re-initialization, then a corresponding schema node
should be defined, with an appropriate type, to indicate
the last discontinuity.

The counter32 type should not be used for configuration
schema nodes.  A default statement SHOULD NOT be used in
combination with the type counter32.

In the value set and its semantics, this type is equivalent
to the Counter32 type of the SMIv2.

The counter32 type represents a non-negative integer
that monotonically increases until it reaches a
maximum value of 2^32-1 (4294967295 decimal), when it
wraps around and starts increasing again from zero.

Counters have no defined 'initial' value, and thus, a
single value of a counter has (in general) no information
content.  Discontinuities in the monotonically increasing
value normally occur at re-initialization of the
management system, and at other times as specified in the
description of a schema node using this type.  If such
other times can occur, for example, the creation of
a schema node of type counter32 at times other than
re-initialization, then a corresponding schema node
should be defined, with an appropriate type, to indicate
the last discontinuity.

The counter32 type should not be used for configuration
schema nodes.  A default statement SHOULD NOT be used in
combination with the type counter32.

In the value set and its semantics, this type is equivalent
to the Counter32 type of the SMIv2.

A 64-bit counter. A counter value is a monotonically increasing
value which is used to express a count of a number of
occurrences of a particular event or entity. When a counter64
reaches its maximum value, 2^64-1, it loops to zero.
Discontinuities in a counter are generally triggered only when
the counter is reset to zero, through operator or system
intervention.

The counter64 type represents a non-negative integer
that monotonically increases until it reaches a
maximum value of 2^64-1 (18446744073709551615 decimal),
when it wraps around and starts increasing again from zero.

Counters have no defined 'initial' value, and thus, a
single value of a counter has (in general) no information
content.  Discontinuities in the monotonically increasing
value normally occur at re-initialization of the
management system, and at other times as specified in the
description of a schema node using this type.  If such
other times can occur, for example, the creation of
a schema node of type counter64 at times other than
re-initialization, then a corresponding schema node
should be defined, with an appropriate type, to indicate
the last discontinuity.

The counter64 type should not be used for configuration
schema nodes.  A default statement SHOULD NOT be used in
combination with the type counter64.

In the value set and its semantics, this type is equivalent
to the Counter64 type of the SMIv2.

The counter64 type represents a non-negative integer
that monotonically increases until it reaches a
maximum value of 2^64-1 (18446744073709551615 decimal),
when it wraps around and starts increasing again from zero.

Counters have no defined 'initial' value, and thus, a
single value of a counter has (in general) no information
content.  Discontinuities in the monotonically increasing
value normally occur at re-initialization of the
management system, and at other times as specified in the
description of a schema node using this type.  If such
other times can occur, for example, the creation of
a schema node of type counter64 at times other than
re-initialization, then a corresponding schema node
should be defined, with an appropriate type, to indicate
the last discontinuity.

The counter64 type should not be used for configuration
schema nodes.  A default statement SHOULD NOT be used in
combination with the type counter64.

In the value set and its semantics, this type is equivalent
to the Counter64 type of the SMIv2.

The Coupling Flag (CF) allows the choice between two modes of
operation of the rate enforcement algorithm.

When CF is set to 0, the long term average rate of Service
Frames that are declared Yellow is bound by EIR.

When CF is set to 1, the long term average rate of Service
Frames that are declared Yellow is bound by CIR+EIR depending
on the volume of offered Service Frames which are declared
Green.

In both cases, the burst size of Service Frames which are
declared Yellow is bound by EBS.

The crypt-hash type is used to store passwords using
a hash function.  The algorithms for applying the hash
function and encoding the result are implemented in
various UNIX systems as the function crypt(3).

A value of this type matches one of the forms:

  $0$<clear text password>
  $<id>$<salt>$<password hash>
  $<id>$<parameter>$<salt>$<password hash>

The '$0$' prefix signals that the value is clear text.  When
such a value is received by the server, a hash value is
calculated, and the string '$<id>$<salt>$' or
$<id>$<parameter>$<salt>$ is prepended to the result.  This
value is stored in the configuration data store.
If a value starting with '$<id>$', where <id> is not '0', is
received, the server knows that the value already represents a
hashed value and stores it 'as is' in the data store.

When a server needs to verify a password given by a user, it
finds the stored password hash string for that user, extracts
the salt, and calculates the hash with the salt and given
password as input.  If the calculated hash value is the same
as the stored value, the password given by the client is
accepted.

This type defines the following hash functions:

  id | hash function | feature
  ---+---------------+-------------------
   1 | MD5           | crypt-hash-md5
   5 | SHA-256       | crypt-hash-sha-256
   6 | SHA-512       | crypt-hash-sha-512

The server indicates support for the different hash functions
by advertising the corresponding feature.

The crypt-hash type is used to store passwords using
a hash function.  The algorithms for applying the hash
function and encoding the result are implemented in
various UNIX systems as the function crypt(3).

A value of this type matches one of the forms:

  $0$<clear text password>
  $<id>$<salt>$<password hash>
  $<id>$<parameter>$<salt>$<password hash>

The '$0$' prefix signals that the value is clear text.  When
such a value is received by the server, a hash value is
calculated, and the string '$<id>$<salt>$' or
$<id>$<parameter>$<salt>$ is prepended to the result.  This
value is stored in the configuration data store.

If a value starting with '$<id>$', where <id> is not '0', is
received, the server knows that the value already represents a
hashed value, and stores it as is in the data store.

When a server needs to verify a password given by a user, it
finds the stored password hash string for that user, extracts
the salt, and calculates the hash with the salt and given
password as input.  If the calculated hash value is the same
as the stored value, the password given by the client is
accepted.

This type defines the following hash functions:

  id | hash function | feature
  ---+---------------+-------------------
   1 | MD5           | crypt-hash-md5
   5 | SHA-256       | crypt-hash-sha-256
   6 | SHA-512       | crypt-hash-sha-512

The server indicates support for the different hash functions
by advertising the corresponding feature.

A password that is hashed based on the hash algorithm
indicated by the prefix in the string.  The string
takes the following form, based on the Unix crypt function:

$<id>[$<param>=<value>(,<param>=<value>)*][$<salt>[$<hash>]]

Common hash functions include:

id  | hash function
---+---------------
 1 | MD5
 2a| Blowfish
 2y| Blowfish (correct handling of 8-bit chars)
 5 | SHA-256
 6 | SHA-512

These may not all be supported by a target device.

This type identifies the cryptographic algorithm

Control connection state

The value rang for cv packet detect multiplier

The value rang for cv packet transmit interval.

control-word negotiation preference type

Duration in ms of the MAC cycle.

A cycle number represented in the format YYYYMMDD.HHMMSS
where YYYY represents the year, MM the month (1..12), DD
the day of the months (01..31), HH the hour (00..23), MM
the minute (00..59), and SS the second (00..59).  The cycle
number is using Coordinated Universal Time (UTC).

Data rate in kbps.

A type which represents the rate at which data is being
transferred.

A type which represents the rate at which data is being
transferred. A special value, 'undetermined', is used to
indicate the data rate is undetermined.

The datapath-id type represents an OpenFlow
datapath identifier. The lower 48-bits are for
a MAC address, while the upper 16-bits are
implementer-defined.

A datastore identity reference.

A full UTC date, expressed in the format described in RFC3339.
That is to say:

YYYY-MM-DD

where YYYY is the year, MM is the month expressed as a two-digit
month (zero padding if required), DD is the day of the month,
expressed as a two digit value.

XSD date string type.

Represents a specific date in YYYY-MM-DD format.

A date and time, expressed in the format described in RFC3339.
That is to say:

YYYY-MM-DDTHH:MM:SSZ+-hh:mm

where YYYY is the year, MM is the month expressed as a two-digit
month (zero padding if required), DD is the day of the month,
expressed as a two digit value. T is the literal character 'T',
HH is the hour of the day expressed as a two digit number, using
the 24-hour clock, MM is the minute of the hour expressed as a
two digit number. Z is the literal character 'Z', followed by a
timezone offset expressed in hours (hh) and minutes (mm), both
expressed as two digit numbers. The time offset is specified as
a positive or negative offset to UTC using the '+' or '-'
character preceding the offset.

Optionally, fractional seconds can be expressed after the minute
of the hour as a decimal number of unspecified precision
reflecting fractions of a second.

The date-and-time type is a profile of the ISO 8601
standard for representation of dates and times using the
Gregorian calendar.  The profile is defined by the
date-time production in Section 5.6 of RFC 3339.

The date-and-time type is compatible with the dateTime XML
schema type with the following notable exceptions:

(a) The date-and-time type does not allow negative years.

(b) The date-and-time time-offset -00:00 indicates an unknown
    time zone (see RFC 3339) while -00:00 and +00:00 and Z
    all represent the same time zone in dateTime.

(c) The canonical format (see below) of data-and-time values
    differs from the canonical format used by the dateTime XML
    schema type, which requires all times to be in UTC using
    the time-offset 'Z'.

This type is not equivalent to the DateAndTime textual
convention of the SMIv2 since RFC 3339 uses a different
separator between full-date and full-time and provides
higher resolution of time-secfrac.

The canonical format for date-and-time values with a known time
zone uses a numeric time zone offset that is calculated using
the device's configured known offset to UTC time.  A change of
the device's offset to UTC time will cause date-and-time values
to change accordingly.  Such changes might happen periodically
in case a server follows automatically daylight saving time
(DST) time zone offset changes.  The canonical format for
date-and-time values with an unknown time zone (usually
referring to the notion of local time) uses the time-offset
-00:00.

The date-and-time type is a profile of the ISO 8601
standard for representation of dates and times using the
Gregorian calendar.  The profile is defined by the
date-time production in Section 5.6 of RFC 3339.

The date-and-time type is compatible with the dateTime XML
schema type with the following notable exceptions:

(a) The date-and-time type does not allow negative years.

(b) The date-and-time time-offset -00:00 indicates an unknown
    time zone (see RFC 3339) while -00:00 and +00:00 and Z all
    represent the same time zone in dateTime.

(c) The canonical format (see below) of data-and-time values
    differs from the canonical format used by the dateTime XML
    schema type, which requires all times to be in UTC using the
    time-offset 'Z'.

This type is not equivalent to the DateAndTime textual
convention of the SMIv2 since RFC 3339 uses a different
separator between full-date and full-time and provides
higher resolution of time-secfrac.

The canonical format for date-and-time values with a known time
zone uses a numeric time zone offset that is calculated using
the device's configured known offset to UTC time.  A change of
the device's offset to UTC time will cause date-and-time values
to change accordingly.  Such changes might happen periodically
in case a server follows automatically daylight saving time
(DST) time zone offset changes.  The canonical format for
date-and-time values with an unknown time zone (usually referring
to the notion of local time) uses the time-offset -00:00.

XSD date and time string type.

A day of a month of the Gregorian calendar.

A day of a month or a wildcard indicating all days
of a month.

Used to reference a DBA profile.

Amplifier Power in dBm

The test voltages for the measurement of the 4-element DC
resistance, VDCTR (Tip-to-Ring), VDCRT (Ring-to-Tip), VDCTG
(Tip-to-Ground), and VDCRG (Ring-to-Ground), shall be
represented in linear format. The range of valid values is from
-150 V to +150 V with a granularity of 0.1 V.

XSD decimal data type.
[To do: not sure if this is a bounded real number
 or an unbounded real number.].

Type used to specify route disposition in
a policy chain

NETCONF 'default-operation' Element Content

The namespace of defect status type