Typedefs

NETCONF Access Operation.

Action taken by the server when a particular
rule matches.

This typedef is a YANG enumeration of IANA-registered address
family numbers (AFN).

The definition of this textual convention with the
addition of newly assigned values is published
periodically by the IANA, in either the Assigned
Numbers RFC, or some derivative of it specific to
Internet Network Management number assignments.
(The latest arrangements can be obtained by
contacting the IANA.)

The enumerations are described as:

other(0),    -- none of the following
ipV4(1),     -- IP Version 4
ipV6(2),     -- IP Version 6
nsap(3),     -- NSAP
hdlc(4),     -- (8-bit multidrop)
bbn1822(5),
all802(6),   -- (includes all 802 media
	     --   plus Ethernet 'canonical format')
e163(7),
e164(8),     -- (SMDS, Frame Relay, ATM)
f69(9),      -- (Telex)
x121(10),    -- (X.25, Frame Relay)
ipx(11),     -- IPX (Internet Protocol Exchange)
appleTalk(12),  -- Apple Talk
decnetIV(13),   -- DEC Net Phase IV
banyanVines(14),  -- Banyan Vines
e164withNsap(15),
	     -- (E.164 with NSAP format subaddress)
dns(16),     -- (Domain Name System)
distinguishedName(17), -- (Distinguished Name, per X.500)
asNumber(18), -- (16-bit quantity, per the AS number space)
xtpOverIpv4(19),  -- XTP over IP version 4
xtpOverIpv6(20),  -- XTP over IP version 6
xtpNativeModeXTP(21),  -- XTP native mode XTP
fibreChannelWWPN(22),  -- Fibre Channel World-Wide Port Name
fibreChannelWWNN(23),  -- Fibre Channel World-Wide Node Name
gwid(24),    -- Gateway Identifier
reserved(65535)

Requests for new values should be made to IANA via
email (iana@iana.org).

Represents and SnmpAdminString as defined in RFC 3411.

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

Denotes a transport service address.  This is identical to
the TAddress textual convention (SNMPv2-SMI) except that
zero-length values are permitted.

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.

XSD universal resource identifier string type.

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.

XSD base64 binary encoded string

The rate, in bits/second, that data  may  move
in  the context.  Applicable contexts minimally
include the speed of an  interface  or  virtual
circuit, the data rate of a (potentially aggre-
gated) data flow, or the data rate to be  allo-
cated for use by a flow.

The number of octets of IP Data, including  IP
Headers, that a stream may send without concern
for policing.

XSD 8 bit signed integer.

Add 'none' to standard enumerations

Specifies how edits will be applied in config mode.

NETCONF 'confirm-timeout' Element Content

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 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 crypt-hash type is used to store passwords using
a hash function.  This type is implemented in various UNIX
systems as the function crypt(3).
When a clear text value is set to a leaf of this type, the
server calculates a password hash, and stores the result
in the datastore.  Thus, the password is never stored in
clear text.

When a leaf of this type is read, the stored password hash is
returned.

A value of this type matches one of the forms:

  $0$<clear text password>
  $<id>$<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>$' is prepended to the
result, where <salt> is a random 2-16 characters long salt
used to generate the digest.  This value is stored in the
configuration data store.

If a value starting with '$<id>$<salt>$' 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
correct.

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.

XSD date string type.

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

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.

A date-time specification.

field  octets  contents                  range
-----  ------  --------                  -----
  1      1-2   year*                     0..65536
  2       3    month                     1..12
  3       4    day                       1..31
  4       5    hour                      0..23
  5       6    minutes                   0..59
  6       7    seconds                   0..60
	       (use 60 for leap-second)
  7       8    deci-seconds              0..9
  8       9    direction from UTC        '+' / '-'
  9      10    hours from UTC*           0..13
 10      11    minutes from UTC          0..59

* Notes:
- the value of year is in network-byte order
- daylight saving time in New Zealand is +13

For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be
displayed as:

		 1992-5-26,13:30:15.0,-4:0

Note that if only local time is known, then timezone
information (fields 8-10) is not present.

XSD date and time string type.

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

NETCONF 'default-operation' Element Content

Type of comparison output requested.

Direction of packets going through an interface or
linecard.

YANG version of the SMIv2 DisplayString TEXTUAL-CONVENTION.

Represents textual information taken from the NVT ASCII

character set, as defined in pages 4, 10-11 of RFC 854.

To summarize RFC 854, the NVT ASCII repertoire specifies:

  - the use of character codes 0-127 (decimal)

  - the graphics characters (32-126) are interpreted as
    US ASCII

  - NUL, LF, CR, BEL, BS, HT, VT and FF have the special
    meanings specified in RFC 854

  - the other 25 codes have no standard interpretation

  - the sequence 'CR LF' means newline

  - the sequence 'CR NUL' means carriage-return

  - an 'LF' not preceded by a 'CR' means moving to the
    same column on the next line.

  - the sequence 'CR x' for any x other than LF or NUL is
    illegal.  (Note that this also means that a string may
    end with either 'CR LF' or 'CR NUL', but not with CR.)

Any object defined using this syntax may not exceed 255
characters in length.

The domain-name type represents a DNS domain name.  The
name SHOULD be fully qualified whenever possible.

Internet domain names are only loosely specified.  Section
3.5 of RFC 1034 recommends a syntax (modified in Section
2.1 of RFC 1123).  The pattern above is intended to allow
for current practice in domain name use, and some possible
future expansion.  It is designed to hold various types of
domain names, including names used for A or AAAA records
(host names) and other records, such as SRV records.  Note
that Internet host names have a stricter syntax (described
in RFC 952) than the DNS recommendations in RFCs 1034 and
1123, and that systems that want to store host names in
schema nodes using the domain-name type are recommended to
adhere to this stricter standard to ensure interoperability.

The encoding of DNS names in the DNS protocol is limited
to 255 characters.  Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL
byte, only 253 characters can appear in the textual dotted
notation.

The description clause of schema nodes using the domain-name
type MUST describe when and how these names are resolved to
IP addresses.  Note that the resolution of a domain-name value
may require to query multiple DNS records (e.g., A for IPv4
and AAAA for IPv6).  The order of the resolution process and
which DNS record takes precedence can either be defined
explicitely or it may depend on the configuration of the
resolver.

Domain-name values use the US-ASCII encoding.  Their canonical
format uses lowercase US-ASCII characters.  Internationalized
domain names MUST be encoded in punycode as described in RFC
3492

A Differentiated Services Code-Point that may be used for
marking a traffic stream.

The dscp type represents a Differentiated Services Code-Point
that may be used for marking packets in a traffic stream.

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

The IP header Differentiated Services Code-Point that may be



used for discriminating among traffic streams. The value -1 is
used to indicate a wild card i.e. any value.

XSD duration string type.

NETCONF 'operation' attribute values

NETCONF 'operation' attribute values

The Engine ID specified as a list of colon-specified hexa-
decimal octets e.g. '4F:4C:41:71'.

XSD ENTITIES attribute type.

XSD ENTITY attribute type.

 Represents the various possible administrative states.





A value of 'locked' means the resource is administratively
prohibited from use.  A value of 'shuttingDown' means that
usage is administratively limited to current instances of
use.  A value of 'unlocked' means the resource is not
administratively prohibited from use.  A value of
'unknown' means that this resource is unable to
report administrative state.

 Represents the possible values of alarm status.
An Alarm [RFC3877] 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 entity and it is not under
repair.

When the 'value of underRepair' is set, the resource is
currently being repaired, which, depending on the
implementation, may make the other values in this bit
string not meaningful.

When the value of 'critical' is set, one or more critical
alarms are active against the resource.  When the value
of 'major' is set, one or more major alarms are active
against the resource.  When the value of 'minor' is set,
one or more minor alarms are active against the resource.
When the value of 'warning' is set, one or more warning
alarms are active against the resource.  When the value
of 'indeterminate' is set, one or more alarms of whose
perceived severity cannot be determined are active
against this resource.

A value of 'unknown' means that this resource is
unable to report alarm state.

 Represents the possible values of operational states.

A value of 'disabled' means the resource is totally
inoperable.  A value of 'enabled' means the resource
is partially or fully operable.  A value of 'testing'
means the resource is currently being tested
and cannot therefore report whether it is operational
or not.  A value of 'unknown' means that this
resource is unable to report operational state.

An object using this data type represents a data scaling
factor, represented with an International System of Units
(SI) prefix.  The actual data units are determined by
examining an object of this type together with the
associated EntitySensorDataType object.

An object of this type SHOULD be defined together with
objects of type EntitySensorDataType and
EntitySensorPrecision.  Together, associated objects of
these three types are used to identify the semantics of an
object of type EntitySensorValue.

An object using this data type represents the Entity Sensor
measurement data type associated with a physical sensor
value. The actual data units are determined by examining an
object of this type together with the associated
EntitySensorDataScale object.

An object of this type SHOULD be defined together with
objects of type EntitySensorDataScale and
EntitySensorPrecision.  Together, associated objects of
these three types are used to identify the semantics of an
object of type EntitySensorValue.






Valid values are:

   other(1):        a measure other than those listed below
   unknown(2):      unknown measurement, or arbitrary,
		    relative numbers
   voltsAC(3):      electric potential
   voltsDC(4):      electric potential
   amperes(5):      electric current
   watts(6):        power
   hertz(7):        frequency
   celsius(8):      temperature
   percentRH(9):    percent relative humidity
   rpm(10):         shaft revolutions per minute
   cmm(11),:        cubic meters per minute (airflow)
   truthvalue(12):  value takes { true(1), false(2) }

An object using this data type represents a sensor
precision range.

An object of this type SHOULD be defined together with
objects of type EntitySensorDataType and
EntitySensorDataScale.  Together, associated objects of
these three types are used to identify the semantics of an
object of type EntitySensorValue.

If an object of this type contains a value in the range 1 to
9, it represents the number of decimal places in the
fractional part of an associated EntitySensorValue fixed-
point number.

If an object of this type contains a value in the range -8
to -1, it represents the number of accurate digits in the
associated EntitySensorValue fixed-point number.

The value zero indicates the associated EntitySensorValue
object is not a fixed-point number.

Agent implementors must choose a value for the associated
EntitySensorPrecision object so that the precision and



accuracy of the associated EntitySensorValue object is
correctly indicated.

For example, a physical entity representing a temperature
sensor that can measure 0 degrees to 100 degrees C in 0.1
degree increments, +/- 0.05 degrees, would have an
EntitySensorPrecision value of '1', an EntitySensorDataScale
value of 'units(9)', and an EntitySensorValue ranging from
'0' to '1000'.  The EntitySensorValue would be interpreted
as 'degrees C * 10'.

An object using this data type represents the operational
status of a physical sensor.

The value 'ok(1)' indicates that the agent can obtain the
sensor value.

The value 'unavailable(2)' indicates that the agent
presently cannot obtain the sensor value.

The value 'nonoperational(3)' indicates that the agent
believes the sensor is broken.  The sensor could have a hard
failure (disconnected wire), or a soft failure such as out-
of-range, jittery, or wildly fluctuating readings.

An object using this data type represents an Entity Sensor
value.
An object of this type SHOULD be defined together with
objects of type EntitySensorDataType, EntitySensorDataScale
and EntitySensorPrecision.  Together, associated objects of
those three types are used to identify the semantics of an
object of this data type.

The semantics of an object using this data type are
determined by the value of the associated
EntitySensorDataType object.

If the associated EntitySensorDataType object is equal to
'voltsAC(3)', 'voltsDC(4)', 'amperes(5)', 'watts(6),
'hertz(7)', 'celsius(8)', or 'cmm(11)', then an object of
this type MUST contain a fixed point number ranging from
-999,999,999 to +999,999,999.  The value -1000000000
indicates an underflow error. The value +1000000000
indicates an overflow error.  The EntitySensorPrecision
indicates how many fractional digits are represented in the
associated EntitySensorValue object.

If the associated EntitySensorDataType object is equal to
'percentRH(9)', then an object of this type MUST contain a
number ranging from 0 to 100.

If the associated EntitySensorDataType object is equal to
'rpm(10)', then an object of this type MUST contain a number
ranging from -999,999,999 to +999,999,999.

If the associated EntitySensorDataType object is equal to
'truthvalue(12)', then an object of this type MUST contain
either the value 'true(1)' or the value 'false(2)'.



If the associated EntitySensorDataType object is equal to
'other(1)' or unknown(2)', then an object of this type MUST
contain a number ranging from -1000000000 to 1000000000.

 Represents the possible values of standby status.

A value of 'hotStandby' means the resource is not
providing service, but it will be immediately able to
take over the role of the resource to be backed up,
without the need for initialization activity, and will
contain the same information as the resource to be
backed up.  A value of 'coldStandy' means that the
resource is to back up another resource, but will not
be immediately able to take over the role of a resource
to be backed up, and will require some initialization
activity.  A value of 'providingService' means the
resource is providing service.  A value of
'unknown' means that this resource is unable to
report standby state.

 Represents the possible values of usage states.
A value of 'idle' means the resource is servicing no
users.  A value of 'active' means the resource is
currently in use and it has sufficient spare capacity
to provide for additional users.  A value of 'busy'
means the resource is currently in use, but it
currently has no spare capacity to provide for
additional users.  A value of 'unknown' means
that this resource is unable to report usage state.

The status of a table entry.

Setting this object to the value invalid(4) has the
effect of invalidating the corresponding entry.
That is, it effectively disassociates the mapping
identified with said entry.
It is an implementation-specific matter as to whether
the agent removes an invalidated entry from the table.
Accordingly, management stations must be prepared to
receive tabular information from agents that corresponds
to entries currently not in use.  Proper
interpretation of such entries requires examination
of the relevant EntryStatus object.

An existing instance of this object cannot be set to
createRequest(2).  This object may only be set to
createRequest(2) when this instance is created.  When
this object is created, the agent may wish to create
supplemental object instances with default values
to complete a conceptual row in this table.  Because the

creation of these default objects is entirely at the option
of the agent, the manager must not assume that any will be
created, but may make use of any that are created.
Immediately after completing the create operation, the agent
must set this object to underCreation(3).

When in the underCreation(3) state, an entry is allowed to
exist in a possibly incomplete, possibly inconsistent state,
usually to allow it to be modified in multiple PDUs.  When in
this state, an entry is not fully active.
Entries shall exist in the underCreation(3) state until
the management station is finished configuring the entry
and sets this object to valid(1) or aborts, setting this
object to invalid(4).  If the agent determines that an
entry has been in the underCreation(3) state for an
abnormally long time, it may decide that the management
station has crashed.  If the agent makes this decision,
it may set this object to invalid(4) to reclaim the
entry.  A prudent agent will understand that the
management station may need to wait for human input
and will allow for that possibility in its
determination of this abnormally long period.

An entry in the valid(1) state is fully configured and
consistent and fully represents the configuration or
operation such a row is intended to represent.  For
example, it could be a statistical function that is
configured and active, or a filter that is available
in the list of filters processed by the packet capture
process.

A manager is restricted to changing the state of an entry in
the following ways:

     To:       valid  createRequest  underCreation  invalid
From:
valid             OK             NO             OK       OK
createRequest    N/A            N/A            N/A      N/A
underCreation     OK             NO             OK       OK
invalid           NO             NO             NO       OK
nonExistent       NO             OK             NO       OK

In the table above, it is not applicable to move the state
from the createRequest state to any other state because the
manager will never find the variable in that state.  The
nonExistent state is not a value of the enumeration, rather
it means that the entryStatus variable does not exist at all.

An agent may allow an entryStatus variable to change state in
additional ways, so long as the semantics of the states are
followed.  This allowance is made to ease the implementation of
the agent and is made despite the fact that managers should
never exercise these additional state transitions.

NETCONF Error Severity

NETCONF Error Severity

NETCONF Error Tag

NETCONF Error Tag

NETCONF 'error-option' Element Content

NETCONF Error Type

Reasons for failures in an attempt to perform a management
request.

The first group of errors, numbered less than 0, are related
to problems in sending the request.  The existence of a
particular error code here does not imply that all
implementations are capable of sensing that error and


returning that code.

The second group, numbered greater than 0, are copied
directly from SNMP protocol operations and are intended to
carry exactly the meanings defined for the protocol as returned
in an SNMP response.

localResourceLack       some local resource such as memory
			lacking or
			mteResourceSampleInstanceMaximum
			exceeded
badDestination          unrecognized domain name or otherwise
			invalid destination address
destinationUnreachable  can't get to destination address
noResponse              no response to SNMP request
badType                 the data syntax of a retrieved object
			as not as expected
sampleOverrun           another sample attempt occurred before
			the previous one completed

NETCONF 'filter' Attribute Content

Conversion Output Formats.

The gauge32 type represents a non-negative integer, which
may increase or decrease, but shall never exceed a maximum
value, nor fall below a minimum value.  The maximum value
cannot be greater than 2^32-1 (4294967295 decimal), and
the minimum value cannot be smaller than 0.  The value of
a gauge32 has its maximum value whenever the information
being modeled is greater than or equal to its maximum
value, and has its minimum value whenever the information
being modeled is smaller than or equal to its minimum value.
If the information being modeled subsequently decreases
below (increases above) the maximum (minimum) value, the
gauge32 also decreases (increases).

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

The gauge64 type represents a non-negative integer, which
may increase or decrease, but shall never exceed a maximum
value, nor fall below a minimum value.  The maximum value
cannot be greater than 2^64-1 (18446744073709551615), and
the minimum value cannot be smaller than 0.  The value of
a gauge64 has its maximum value whenever the information
being modeled is greater than or equal to its maximum
value, and has its minimum value whenever the information
being modeled is smaller than or equal to its minimum value.
If the information being modeled subsequently decreases
below (increases above) the maximum (minimum) value, the
gauge64 also decreases (increases).

In the value set and its semantics, this type is equivalent
to the CounterBasedGauge64 SMIv2 textual convention defined
in RFC 2856

XSD day string type.

XSD month string type.

XSD month and day string type.

Name of administrative group to which
users can be assigned.

XSD year string type.

XSD year and month string type.

XSD hex binary encoded string

The host type represents either an IP address or a DNS
domain name.

This data type is used as the syntax of the 'type'
leaf in the 'interface' list in the YANG module
ietf-interface.

The definition of this typedef with the
addition of newly assigned values is published
periodically by the IANA, in either the Assigned
Numbers RFC, or some derivative of it specific to
Internet Network Management number assignments.  (The
latest arrangements can be obtained by contacting the
IANA.)

Requests for new values should be made to IANA via
email (iana&iana.org).

A timezone location as defined by the IANA timezone
database (http://www.iana.org/time-zones)

This data type is used as the syntax of the ifType
object in the (updated) definition of MIB-II's
ifTable.

The definition of this textual convention with the
addition of newly assigned values is published
periodically by the IANA, in either the Assigned
Numbers RFC, or some derivative of it specific to
Internet Network Management number assignments.  (The
latest arrangements can be obtained by contacting the
IANA.)

Requests for new values should be made to IANA via
email (iana@iana.org).

The relationship between the assignment of ifType
values and of OIDs to particular media-specific MIBs
is solely the purview of IANA and is subject to change
without notice.  Quite often, a media-specific MIB's
OID-subtree assignment within MIB-II's 'transmission'
subtree will be the same as its ifType value.
However, in some circumstances this will not be the
case, and implementors must not pre-assume any
specific relationship between ifType values and
transmission subtree OIDs.

The multicast routing protocol.  Inclusion of values for
multicast routing protocols is not intended to imply that
those protocols need be supported.

A mechanism for learning routes.  Inclusion of values for
routing protocols is not intended to imply that those
protocols need be supported.

The encapsulation method used by a tunnel. The value
direct indicates that a packet is encapsulated
directly within a normal IP header, with no
intermediate header, and unicast to the remote tunnel
endpoint (e.g., an RFC 2003 IP-in-IP tunnel, or an RFC
1933 IPv6-in-IPv4 tunnel). The value minimal indicates
that a Minimal Forwarding Header (RFC 2004) is
inserted between the outer header and the payload
packet. The value UDP indicates that the payload
packet is encapsulated within a normal UDP packet
(e.g., RFC 1234).

The values sixToFour, sixOverFour, and isatap
indicates that an IPv6 packet is encapsulated directly
within an IPv4 header, with no intermediate header,
and unicast to the destination determined by the 6to4,
6over4, or ISATAP protocol.

The remaining protocol-specific values indicate that a
header of the protocol of that name is inserted
between the outer header and the payload header.

The assignment policy for IANAtunnelType values is
identical to the policy for assigning IANAifType
values.

XSD ID attribute type.

Indicates an identifier or empty string to use the
schema or application defined default.

XSD IDREF attribute type.

XSD IDREFS attribute type.

Type for Information Element identifiers.

Type for Information Element names.  Whitespaces
are not allowed.

IfDirection specifies a direction of data travel on an
interface. 'inbound' traffic is operated on during reception from
the interface, while 'outbound' traffic is operated on prior to
transmission on the interface.

This corresponds to the DisplayString textual
convention of SNMPv2-TC, which is used for ifName in the IF
MIB module.

Requested indent amount.
Only a limited range of line indent values are allowed.

An integer which may be used as a table index.

An integer which may be used as a new Index in a table.

The special value of 0 indicates that no more new entries can be
created in the relevant table.

When a MIB is used for configuration, an object with this SYNTAX
always contains a legal value (if non-zero) for an index that is
not currently used in the relevant table. The Command Generator
(Network Management Application) reads this variable and uses the
(non-zero) value read when creating a new row with an SNMP SET.
When the SET is performed, the Command Responder (agent) must
determine whether the value is indeed still unused; Two Network
Management Applications may attempt to create a row
(configuration entry) simultaneously and use the same value. If
it is currently unused, the SET succeeds and the Command
Responder (agent) changes the value of this object, according to
an implementation-specific algorithm.  If the value is in use,



however, the SET fails.  The Network Management Application must
then re-read this variable to obtain a new usable value.

An OBJECT-TYPE definition using this SYNTAX MUST specify the
relevant table for which the object is providing this
functionality.

Denotes a generic Internet address.

An InetAddress value is always interpreted within the context
of an InetAddressType value.  Every usage of the InetAddress
textual convention is required to specify the InetAddressType
object that provides the context.  It is suggested that the
InetAddressType object be logically registered before the
object(s) that use the InetAddress textual convention, if
they appear in the same logical row.

The value of an InetAddress object must always be
consistent with the value of the associated InetAddressType
object.  Attempts to set an InetAddress object to a value
inconsistent with the associated InetAddressType
must fail with an inconsistentValue error.

When this textual convention is used as the syntax of an
index object, there may be issues with the limit of 128
sub-identifiers specified in SMIv2, STD 58.  In this case,
the object definition MUST include a 'SIZE' clause to
limit the number of potential instance sub-identifiers;
otherwise the applicable constraints MUST be stated in
the appropriate conceptual row DESCRIPTION clauses, or
in the surrounding documentation if there is no single
DESCRIPTION clause that is appropriate.

Represents a DNS domain name.  The name SHOULD be fully
qualified whenever possible.

The corresponding InetAddressType is dns(16).

The DESCRIPTION clause of InetAddress objects that may have
InetAddressDNS values MUST fully describe how (and when)
these names are to be resolved to IP addresses.

The resolution of an InetAddressDNS value may require to
query multiple DNS records (e.g., A for IPv4 and AAAA for
IPv6).  The order of the resolution process and which DNS
record takes precedence depends on the configuration of the
resolver.

This textual convention SHOULD NOT be used directly in object
definitions, as it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or in
conjunction with InetAddressType, as a pair.

Represents an IPv4 network address:

Octets   Contents         Encoding
 1-4     IPv4 address     network-byte order

The corresponding InetAddressType value is ipv4(1).

This textual convention SHOULD NOT be used directly in object
definitions, as it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or in
conjunction with InetAddressType, as a pair.

Represents a non-global IPv4 network address, together
with its zone index:

  Octets   Contents         Encoding
   1-4     IPv4 address     network-byte order
   5-8     zone index       network-byte order

The corresponding InetAddressType value is ipv4z(3).

The zone index (bytes 5-8) is used to disambiguate identical
address values on nodes that have interfaces attached to
different zones of the same scope.  The zone index may contain
the special value 0, which refers to the default zone for each
scope.

This textual convention SHOULD NOT be used directly in object

definitions, as it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or in
conjunction with InetAddressType, as a pair.

Represents an IPv6 network address:

Octets   Contents         Encoding
 1-16    IPv6 address     network-byte order

The corresponding InetAddressType value is ipv6(2).

This textual convention SHOULD NOT be used directly in object
definitions, as it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or in
conjunction with InetAddressType, as a pair.

Represents a non-global IPv6 network address, together
with its zone index:

  Octets   Contents         Encoding
   1-16    IPv6 address     network-byte order
  17-20    zone index       network-byte order

The corresponding InetAddressType value is ipv6z(4).

The zone index (bytes 17-20) is used to disambiguate
identical address values on nodes that have interfaces
attached to different zones of the same scope.  The zone index
may contain the special value 0, which refers to the default
zone for each scope.

This textual convention SHOULD NOT be used directly in object
definitions, as it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or in
conjunction with InetAddressType, as a pair.

Denotes the length of a generic Internet network address
prefix.  A value of n corresponds to an IP address mask
that has n contiguous 1-bits from the most significant
bit (MSB), with all other bits set to 0.

An InetAddressPrefixLength value is always interpreted within
the context of an InetAddressType value.  Every usage of the
InetAddressPrefixLength textual convention is required to
specify the InetAddressType object that provides the
context.  It is suggested that the InetAddressType object be
logically registered before the object(s) that use the
InetAddressPrefixLength textual convention, if they appear
in the same logical row.

InetAddressPrefixLength values larger than
the maximum length of an IP address for a specific
InetAddressType are treated as the maximum significant
value applicable for the InetAddressType.  The maximum
significant value is 32 for the InetAddressType
'ipv4(1)' and 'ipv4z(3)' and 128 for the InetAddressType
'ipv6(2)' and 'ipv6z(4)'.  The maximum significant value
for the InetAddressType 'dns(16)' is 0.

The value zero is object-specific and must be defined as
part of the description of any object that uses this
syntax.  Examples of the usage of zero might include
situations where the Internet network address prefix
is unknown or does not apply.

The upper bound of the prefix length has been chosen to
be consistent with the maximum size of an InetAddress.

A value that represents a type of Internet address.

unknown(0)  An unknown address type.  This value MUST
	    be used if the value of the corresponding
	    InetAddress object is a zero-length string.
	    It may also be used to indicate an IP address
	    that is not in one of the formats defined
	    below.

ipv4(1)     An IPv4 address as defined by the
	    InetAddressIPv4 textual convention.

ipv6(2)     An IPv6 address as defined by the
	    InetAddressIPv6 textual convention.

ipv4z(3)    A non-global IPv4 address including a zone
	    index as defined by the InetAddressIPv4z
	    textual convention.

ipv6z(4)    A non-global IPv6 address including a zone
	    index as defined by the InetAddressIPv6z
	    textual convention.

dns(16)     A DNS domain name as defined by the
	    InetAddressDNS textual convention.

Each definition of a concrete InetAddressType value must be
accompanied by a definition of a textual convention for use
with that InetAddressType.

To support future extensions, the InetAddressType textual
convention SHOULD NOT be sub-typed in object type definitions.
It MAY be sub-typed in compliance statements in order to
require only a subset of these address types for a compliant
implementation.

Implementations must ensure that InetAddressType objects
and any dependent objects (e.g., InetAddress objects) are
consistent.  An inconsistentValue error must be generated
if an attempt to change an InetAddressType object would,
for example, lead to an undefined InetAddress value.  In

particular, InetAddressType/InetAddress pairs must be
changed together if the address type changes (e.g., from
ipv6(2) to ipv4(1)).

Represents an autonomous system number that identifies 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 are currently limited to 16 bits
(0..65535).  There is, however, work in progress to enlarge the
autonomous system number space to 32 bits.  Therefore, this
textual convention uses an Unsigned32 value without a
range restriction in order to support a larger autonomous
system number space.

Represents a 16 bit port number of an Internet transport

layer protocol.  Port numbers are assigned by IANA.  A
current list of all assignments is available from
<http://www.iana.org/>.

The value zero is object-specific and must be defined as
part of the description of any object that uses this
syntax.  Examples of the usage of zero might include
situations where a port number is unknown, or when the
value zero is used as a wildcard in a filter.

Represents a scope type.  This textual convention can be used
in cases where a MIB has to represent different scope types
and there is no context information, such as an InetAddress
object, that implicitly defines the scope type.

Note that not all possible values have been assigned yet, but
they may be assigned in future revisions of this specification.
Applications should therefore be able to deal with values
not yet assigned.

A value representing a version of the IP protocol.

unknown(0)  An unknown or unspecified version of the IP
	    protocol.

ipv4(1)     The IPv4 protocol as defined in RFC 791 (STD 5).

ipv6(2)     The IPv6 protocol as defined in RFC 2460.

Note that this textual convention SHOULD NOT be used to
distinguish different address types associated with IP
protocols.  The InetAddressType has been designed for this
purpose.

A zone index identifies an instance of a zone of a
specific scope.

The zone index MUST disambiguate identical address
values.  For link-local addresses, the zone index will
typically be the interface index (ifIndex as defined in the
IF-MIB) of the interface on which the address is configured.

The zone index may contain the special value 0, which refers
to the default zone.  The default zone may be used in cases
where the valid zone index is not known (e.g., when a
management application has to write a link-local IPv6
address without knowing the interface index value).  The
default zone SHOULD NOT be used as an easy way out in
cases where the zone index for a non-global IPv6 address
is known.

XSD 32 bit signed integer.

Changed int base type to int32 for YANG

XSD unbounded integer type.
This cannot be given a range like a number.
This pattern does not supoort string representations
of numbers, such as one two three

This type is used by data models that need to reference
interfaces.

A unique value, greater than zero, for each interface or
interface sub-layer in the managed system.  It is
recommended that values are assigned contiguously starting
from 1.  The value for each interface sub-layer must remain
constant at least from one re-initialization of the entity's
network management system to the next re-initialization.

This textual convention is an extension of the
InterfaceIndex convention.  The latter defines a greater
than zero value used to identify an interface or interface
sub-layer in the managed system.  This extension permits the
additional value of zero.  the value zero is object-specific
and must therefore be defined as part of the description of
any object which uses this syntax.  Examples of the usage of
zero might include situations where interface was unknown,
or when none or all interfaces need to be referenced.

This data type is used to model textual information
in some character set.  A network management station
should use a local algorithm to determine which
character set is in use and how it should be
displayed.  Note that this character set may be
encoded with more than one octet per symbol, but will
most often be NVT ASCII. When a size clause is
specified for an object of this type, the size refers
to the length in octets, not the number of symbols.

The ip-address type represents an IP address and is IP
version neutral.  The format of the textual representations
implies the IP version.

The ip-prefix type represents an IP prefix and is IP
version neutral.  The format of the textual representations
implies the IP version.

This value represents the version of the IP protocol.

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

The origin of the address.

manual(2) indicates that the address was manually configured
to a specified address, e.g., by user configuration.

dhcp(4) indicates an address that was assigned to this
system by a DHCP server.

linklayer(5) indicates an address created by IPv6 stateless



auto-configuration.

random(6) indicates an address chosen by the system at
random, e.g., an IPv4 address within 169.254/16, or an RFC
3041 privacy address.

The origin of this prefix.

manual(2) indicates a prefix that was manually configured.

wellknown(3) indicates a well-known prefix, e.g., 169.254/16
for IPv4 auto-configuration or fe80::/10 for IPv6 link-local
addresses.  Well known prefixes may be assigned by IANA,
the address registries, or by specification in a standards
track RFC.

dhcp(4) indicates a prefix that was assigned by a DHCP
server.

routeradv(5) indicates a prefix learned from a router
advertisement.

Note: while IpAddressOriginTC and IpAddressPrefixOriginTC
are similar, they are not identical.  The first defines how
an address was created, while the second defines how a
prefix was found.

The status of an address.  Most of the states correspond to
states from the IPv6 Stateless Address Autoconfiguration
protocol.

The preferred(1) state indicates that this is a valid
address that can appear as the destination or source address
of a packet.

The deprecated(2) state indicates that this is a valid but
deprecated address that should no longer be used as a source
address in new communications, but packets addressed to such
an address are processed as expected.

The invalid(3) state indicates that this isn't a valid
address and it shouldn't appear as the destination or source
address of a packet.

The inaccessible(4) state indicates that the address is not
accessible because the interface to which this address is
assigned is not operational.

The unknown(5) state indicates that the status cannot be
determined for some reason.

The tentative(6) state indicates that the uniqueness of the
address on the link is being verified.  Addresses in this
state should not be used for general communication and
should only be used to determine the uniqueness of the
address.

The duplicate(7) state indicates the address has been
determined to be non-unique on the link and so must not be



used.

The optimistic(8) state indicates the address is available
for use, subject to restrictions, while its uniqueness on
a link is being verified.

In the absence of other information, an IPv4 address is
always preferred(1).

The ipv4-address type represents an IPv4 address in
dotted-quad notation.  The IPv4 address may include a zone
index, separated by a % sign.

The zone index is used to disambiguate identical address
values.  For link-local addresses, the zone index will
typically be the interface index number or the name of an
interface.  If the zone index is not present, the default
zone of the device will be used.

The canonical format for the zone index is the numerical
format

The ipv4-prefix type represents an IPv4 address prefix.
The prefix length is given by the number following the
slash character and must be less than or equal to 32.

A prefix length value of n corresponds to an IP address
mask that has n contiguous 1-bits from the most
significant bit (MSB) and all other bits set to 0.

The canonical format of an IPv4 prefix has all bits of
the IPv4 address set to zero that are not part of the
IPv4 prefix.

The ipv6-address type represents an IPv6 address in full,
mixed, shortened, and shortened-mixed notation.  The IPv6
address may include a zone index, separated by a % sign.

The zone index is used to disambiguate identical address
values.  For link-local addresses, the zone index will
typically be the interface index number or the name of an
interface.  If the zone index is not present, the default
zone of the device will be used.

The canonical format of IPv6 addresses uses the compressed
format described in RFC 4291, Section 2.2, item 2 with the
following additional rules: the :: substitution must be
applied to the longest sequence of all-zero 16-bit chunks
in an IPv6 address.  If there is a tie, the first sequence
of all-zero 16-bit chunks is replaced by ::.  Single
all-zero 16-bit chunks are not compressed.  The canonical
format uses lowercase characters and leading zeros are
not allowed.  The canonical format for the zone index is
the numerical format as described in RFC 4007, Section
11.2.

The flow-label type represents flow identifier or Flow Label
in an IPv6 packet header that may be used to discriminate
traffic flows.

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

The ipv6-prefix type represents an IPv6 address prefix.
The prefix length is given by the number following the
slash character and must be less than or equal 128.

A prefix length value of n corresponds to an IP address
mask that has n contiguous 1-bits from the most
significant bit (MSB) and all other bits set to 0.

The IPv6 address should have all bits that do not belong
to the prefix set to zero.

The canonical format of an IPv6 prefix has all bits of
the IPv6 address set to zero that are not part of the
IPv6 prefix.  Furthermore, IPv6 address is represented
in the compressed format described in RFC 4291, Section
2.2, item 2 with the following additional rules: the ::
substitution must be applied to the longest sequence of
all-zero 16-bit chunks in an IPv6 address.  If there is
a tie, the first sequence of all-zero 16-bit chunks is
replaced by ::.  Single all-zero 16-bit chunks are not
compressed.  The canonical format uses lowercase
characters and leading zeros are not allowed.

This data type is used to model IPv6 address
interface identifiers.  This is a binary string
of up to 8 octets in network byte-order.

Storage size, expressed in units of 1024 bytes.

XML string with a language attribute.

XML string with a language attribute.

XSD language identifier string type.

XML language type for LangString

XML language type for LangString

A number identifying a specific partial-lock granted to a session.
It is allocated by the system, and SHOULD be used in the
partial-unlock operation.

Number of log entries. -1 means all entries

Index into a log buffer.

XSD 64 bit signed integer.

Changed long base type to int64 for YANG

The mac-address type represents an IEEE 802 MAC address.
The canonical representation uses lowercase characters.

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

Represents an 802 MAC address represented in the
`canonical' order defined by IEEE 802.1a, i.e., as if it
were transmitted least significant bit first, even though
802.5 (in contrast to other 802.x protocols) requires MAC
addresses to be transmitted most significant bit first.

The string containing a single asterisk '*' is used
to conceptually represent all possible values
for the particular leaf using this data type.

NETCONF message-id attribute

The size of a message in bytes. This  is  used
to  specify  the  minimum and maximum size of a
message along an integrated services route.

Action taken by the server when a particular
rule matches.

Type of administrative group that can be
assigned to the user, and specified in
an access control rule.

The identityref data type is used to allow as
many groups to be added as needed.  There are
no standard semantics for each identity.
It simply represents a unique group name.

NETCONF Access Rights

General Purpose User Name string.

XSD name string type.

Defines the search mode that should be used
when resolving YANG node names in leafs and
leaf-lists using the UrlPath data type.

Type for 'name' leafs, which are used to identify
specific instances within lists, etc.
Leading and trailing whitespaces are not allowed.

NCX System access control mode.

NCX Session debug logging control enumeration.
Each successive value includes all the previous
messages from lower value enumeration values,
plus the messages for the specified value.

off == no logging is done
write == log write  messages (NOT SUPPORTED IN YUMA)
dev0 == log developer level 0 messages (NOT SUPPORTED
	  IN YUMA)
error == log error messages
warn == log warning messages
info == log info messages
dev1    == log developer level 1 messages (NOT SUPPORTED
	   IN YUMA)
debug  == log debug level 1 messages
debug2 == log debug level 2 messages
debug3 == log debug level 3 messages
debug4 == log debug level 4 messages

Non-negative index value

A string which specifies a module name, or a filespec
which represents a module, with an optional revision date.

      If this string represents a filespec,
      containing any path separation characters, and/or
      ending with the '.yang' or '.yin' extension,
      then only that file location will be checked.

      If this string represents a module name, then
      the module search path will be checked for
      a file with the module name and the '.yang'
      or '.yin.' extension.

      If this string contains a module name
      followed by an 'at sign' character (@),
      followed by a revision string (e.g., foo@2010-01-01),
      then that specific version of the module will be used.

      If this string begins with a '~' character,
      then a username is expected to follow or
      a directory separator character.  If it begins
      with a '$' character, then an environment variable
      name is expected to follow.

      ~/some/path ==> <my-home-dir>/some/path

      ~fred/some/path ==> <fred-home-dir>/some/path

      $workdir/some/path ==> <workdir-env-var>/some/path
   

XSD not-namespace-qualified name string type.

PATHSPEC formatted string indicating the machine-dependent
search path for the NCX programs to use.  Parameters
with this data type can be used to override the
default search order, and insert special work
directories in the search path.

Each component in the string is an absolute or
relative directory path specification.
The colon char ':' is used to separate the path strings.
Whitespace is not allowed in the string at all.

For example, the following string contains 3 paths
that would be used in the order given:

/home/users/testbed1/yang:/home/users/yang:/usr/share/yang

A string which specifies a directory name.

Transport layer port number.

Union of all the Identifier types.

Requested Maximum Line Length

General Purpose NCX Name string.

Qualified Name:
 module-name:NcxName OR owner-name:NcxName.

NCX RPC Type Classifications

NCX Session ID number

XSD unbounded negative integer.
This cannot be given a range like a number.
This pattern does not supoort string representations
of numbers, such as one two three

Enumeration of possible NETCONF datastore types.

XSD NMTOKEN attribute type.

XSD NMTOKENS attribute type.

XSD unbounded non-negative integer.
This cannot be given a range like a number.
This pattern does not supoort string representations
of numbers, such as one two three

XSD unbounded non-positive integer.
This cannot be given a range like a number.
This pattern does not supoort string representations
of numbers, such as one two three

XSD normalized string

XSD NOTATION attribute type.

The object-identifier type represents administratively
assigned names in a registration-hierarchical-name tree.

Values of this type are denoted as a sequence of numerical
non-negative sub-identifier values.  Each sub-identifier
value MUST NOT exceed 2^32-1 (4294967295).  Sub-identifiers
are separated by single dots and without any intermediate
whitespace.

The ASN.1 standard restricts the value space of the first
sub-identifier to 0, 1, or 2.  Furthermore, the value space
of the second sub-identifier is restricted to the range
0 to 39 if the first sub-identifier is 0 or 1.  Finally,
the ASN.1 standard requires that an object identifier
has always at least two sub-identifier.  The pattern
captures these restrictions.

Although the number of sub-identifiers is not limited,
module designers should realize that there may be
implementations that stick with the SMIv2 limit of 128
sub-identifiers.

This type is a superset of the SMIv2 OBJECT IDENTIFIER type
since it is not restricted to 128 sub-identifiers.  Hence,
this type SHOULD NOT be used to represent the SMIv2 OBJECT
IDENTIFIER type, the object-identifier-128 type SHOULD be
used instead.

Requested view format for objects.

The Opaque type supports the capability to pass arbitrary ASN.1
syntax.  A value is encoded using the ASN.1 Basic Encoding Rules
into a string of octets.  This, in turn, is encoded as an OCTET
STRING, in effect 'double-wrapping' the original ASN.1 value.

In the value set and its semantics, this type is equivalent to
the Opaque type of the SMIv2.  This type exists in the SMIv2
solely for backward-compatibility reasons and this is also
true for this YANG data type.

This data type is used to model an administratively
assigned name of the owner of a resource. Implementations
must accept values composed of well-formed NVT ASCII
sequences. In addition, implementations should accept
values composed of well-formed UTF-8 sequences.

It is suggested that this name contain one or more of
the following: IP address, management station name,
network manager's name, location, or phone number.
In some cases the agent itself will be the owner of
an entry.  In these cases, this string shall be set
to a string starting with 'monitor'.

SNMP access control is articulated entirely in terms
of the contents of MIB views; access to a particular
SNMP object instance depends only upon its presence
or absence in a particular MIB view and never upon
its value or the value of related object instances.
Thus, objects of this type afford resolution of
resource contention only among cooperating
managers; they realize no access control function
with respect to uncooperative parties.

This data type is used to model an administratively
assigned name of the owner of a resource.  This information
is taken from the NVT ASCII character set.  It is suggested
that this name contain one or more of the following: ASCII
form of the manager station's transport address, management
station name (e.g., domain name), network management
personnel's name, location, or phone number.  In some cases
the agent itself will be the owner of an entry.  In these
cases, this string shall be set to a string starting with
'agent'.

Represents media- or physical-level addresses represented
as a sequence octets, each octet represented by two hexadecimal
numbers.  Octets are separated by colons.  The canonical
representation uses lowercase characters.

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

Represents media- or physical-level addresses.

An enumerated value which provides an indication of the
general hardware type of a particular physical entity.
There are no restrictions as to the number of
entPhysicalEntries of each entPhysicalClass, which must be
instantiated by an agent.

The enumeration 'other' is applicable if the physical entity
class is known, but does not match any of the supported
values.

The enumeration 'unknown' is applicable if the physical
entity class is unknown to the agent.

The enumeration 'chassis' is applicable if the physical
entity class is an overall container for networking
equipment.  Any class of physical entity, except a stack,
may be contained within a chassis; and a chassis may only
be contained within a stack.




The enumeration 'backplane' is applicable if the physical
entity class is some sort of device for aggregating and
forwarding networking traffic, such as a shared backplane in
a modular ethernet switch.  Note that an agent may model a
backplane as a single physical entity, which is actually
implemented as multiple discrete physical components (within
a chassis or stack).

The enumeration 'container' is applicable if the physical
entity class is capable of containing one or more removable
physical entities, possibly of different types.  For
example, each (empty or full) slot in a chassis will be
modeled as a container.  Note that all removable physical
entities should be modeled within a container entity, such
as field-replaceable modules, fans, or power supplies.  Note
that all known containers should be modeled by the agent,
including empty containers.

The enumeration 'powerSupply' is applicable if the physical
entity class is a power-supplying component.

The enumeration 'fan' is applicable if the physical entity
class is a fan or other heat-reduction component.

The enumeration 'sensor' is applicable if the physical
entity class is some sort of sensor, such as a temperature
sensor within a router chassis.

The enumeration 'module' is applicable if the physical
entity class is some sort of self-contained sub-system.  If
the enumeration 'module' is removable, then it should be
modeled within a container entity, otherwise it should be
modeled directly within another physical entity (e.g., a
chassis or another module).

The enumeration 'port' is applicable if the physical entity
class is some sort of networking port, capable of receiving
and/or transmitting networking traffic.

The enumeration 'stack' is applicable if the physical entity
class is some sort of super-container (possibly virtual),
intended to group together multiple chassis entities.  A
stack may be realized by a 'virtual' cable, a real
interconnect cable, attached to multiple chassis, or may in
fact be comprised of multiple interconnect cables.  A stack
should not be modeled within any other physical entities,
but a stack may be contained within another stack.  Only
chassis entities should be contained within a stack.



The enumeration 'cpu' is applicable if the physical entity
class is some sort of central processing unit.

An arbitrary value that uniquely identifies the physical
entity.  The value should be a small, positive integer.
Index values for different physical entities are not
necessarily contiguous.

This textual convention is an extension of the
PhysicalIndex convention, which defines a greater than zero
value used to identify a physical entity.  This extension
permits the additional value of zero.  The semantics of the
value zero are object-specific and must, therefore, be
defined as part of the description of any object that uses
this syntax.  Examples of the usage of this extension are
situations where none or all physical entities need to be
referenced.

The value of the UDP or TCP Source or Destina-
tion  Port field, a virtual destination port or
generalized port identifier used with the IPSEC
Authentication Header or Encapsulating Security
Payload, or other session discriminator.  If it
is  not  used, the value should be of length 0.
This pair, when coupled with the  IP  Addresses
of the source and destination system and the IP
protocol  field,  uniquely  identifies  a  data
stream.

The port-number type represents a 16-bit port number of an
Internet transport layer protocol such as UDP, TCP, DCCP, or
SCTP.  Port numbers are assigned by IANA.  A current list of
all assignments is available from <http://www.iana.org/>.

Note that the port number value zero is reserved by IANA.  In
situations where the value zero does not make sense, it can
be excluded by subtyping the port-number type.

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

XSD unbounded positive integer.
This cannot be given a range like a number.
This pattern does not supoort string representations
of numbers, such as one two three

The value of the IP Protocol field  of  an  IP
Datagram  Header.  This identifies the protocol
layer above IP.  For example, the  value  6  is
used  for TCP and the value 17 is used for UDP.
The values of this field are defined in the As-
signed Numbers RFC.

XSD namespace-qualified name string type.

The class of service in use by a flow.

The type of response expected from the server
for this request.

This type is used for leafs that reference a route filter.

This type is used for leafs that reference a router
instance.

This type is used for leafs that reference a routing table.

The RowStatus textual convention is used to manage the
creation and deletion of conceptual rows, and is used as the
value of the SYNTAX clause for the status column of a
conceptual row (as described in Section 7.7.1 of [2].)

The status column has six defined values:

     - `active', which indicates that the conceptual row is
     available for use by the managed device;

     - `notInService', which indicates that the conceptual
     row exists in the agent, but is unavailable for use by
     the managed device (see NOTE below); 'notInService' has
     no implication regarding the internal consistency of
     the row, availability of resources, or consistency with
     the current state of the managed device;

     - `notReady', which indicates that the conceptual row
     exists in the agent, but is missing information
     necessary in order to be available for use by the
     managed device (i.e., one or more required columns in
     the conceptual row have not been instanciated);

     - `createAndGo', which is supplied by a management
     station wishing to create a new instance of a
     conceptual row and to have its status automatically set
     to active, making it available for use by the managed
     device;

     - `createAndWait', which is supplied by a management
     station wishing to create a new instance of a
     conceptual row (but not make it available for use by
     the managed device); and,
     - `destroy', which is supplied by a management station
     wishing to delete all of the instances associated with
     an existing conceptual row.

Whereas five of the six values (all except `notReady') may
be specified in a management protocol set operation, only
three values will be returned in response to a management
protocol retrieval operation:  `notReady', `notInService' or
`active'.  That is, when queried, an existing conceptual row
has only three states:  it is either available for use by
the managed device (the status column has value `active');
it is not available for use by the managed device, though
the agent has sufficient information to attempt to make it
so (the status column has value `notInService'); or, it is
not available for use by the managed device, and an attempt
to make it so would fail because the agent has insufficient
information (the state column has value `notReady').

			 NOTE WELL

     This textual convention may be used for a MIB table,
     irrespective of whether the values of that table's
     conceptual rows are able to be modified while it is
     active, or whether its conceptual rows must be taken
     out of service in order to be modified.  That is, it is
     the responsibility of the DESCRIPTION clause of the
     status column to specify whether the status column must
     not be `active' in order for the value of some other
     column of the same conceptual row to be modified.  If
     such a specification is made, affected columns may be
     changed by an SNMP set PDU if the RowStatus would not
     be equal to `active' either immediately before or after
     processing the PDU.  In other words, if the PDU also
     contained a varbind that would change the RowStatus
     value, the column in question may be changed if the
     RowStatus was not equal to `active' as the PDU was
     received, or if the varbind sets the status to a value
     other than 'active'.

Also note that whenever any elements of a row exist, the
RowStatus column must also exist.

To summarize the effect of having a conceptual row with a
status column having a SYNTAX clause value of RowStatus,
consider the following state diagram:

			     STATE
  +--------------+-----------+-------------+-------------
  |      A       |     B     |      C      |      D
  |              |status col.|status column|
  |status column |    is     |      is     |status column
ACTION    |does not exist|  notReady | notInService|  is active
--------------+--------------+-----------+-------------+-------------
set status    |noError    ->D|inconsist- |inconsistent-|inconsistent-
column to     |       or     |   entValue|        Value|        Value
createAndGo   |inconsistent- |           |             |
  |         Value|           |             |
--------------+--------------+-----------+-------------+-------------
set status    |noError  see 1|inconsist- |inconsistent-|inconsistent-
column to     |       or     |   entValue|        Value|        Value
createAndWait |wrongValue    |           |             |
--------------+--------------+-----------+-------------+-------------
set status    |inconsistent- |inconsist- |noError      |noError
column to     |         Value|   entValue|             |
active        |              |           |             |
  |              |     or    |             |
  |              |           |             |
  |              |see 2   ->D|see 8     ->D|          ->D
--------------+--------------+-----------+-------------+-------------
set status    |inconsistent- |inconsist- |noError      |noError   ->C
column to     |         Value|   entValue|             |
notInService  |              |           |             |
  |              |     or    |             |      or
  |              |           |             |
  |              |see 3   ->C|          ->C|see 6
--------------+--------------+-----------+-------------+-------------
set status    |noError       |noError    |noError      |noError   ->A
column to     |              |           |             |      or
destroy       |           ->A|        ->A|          ->A|see 7
--------------+--------------+-----------+-------------+-------------
set any other |see 4         |noError    |noError      |see 5
column to some|              |           |             |
value         |              |      see 1|          ->C|          ->D
--------------+--------------+-----------+-------------+-------------

(1) goto B or C, depending on information available to the
agent.

(2) if other variable bindings included in the same PDU,
provide values for all columns which are missing but
required, and all columns have acceptable values, then
return noError and goto D.

(3) if other variable bindings included in the same PDU,
provide legal values for all columns which are missing but
required, then return noError and goto C.

(4) at the discretion of the agent, the return value may be
either:

     inconsistentName:  because the agent does not choose to
     create such an instance when the corresponding
     RowStatus instance does not exist, or

     inconsistentValue:  if the supplied value is
     inconsistent with the state of some other MIB object's
     value, or

     noError: because the agent chooses to create the
     instance.

If noError is returned, then the instance of the status
column must also be created, and the new state is B or C,
depending on the information available to the agent.  If
inconsistentName or inconsistentValue is returned, the row
remains in state A.

(5) depending on the MIB definition for the column/table,
either noError or inconsistentValue may be returned.

(6) the return value can indicate one of the following
errors:

     wrongValue: because the agent does not support
     notInService (e.g., an agent which does not support
     createAndWait), or

     inconsistentValue: because the agent is unable to take
     the row out of service at this time, perhaps because it
     is in use and cannot be de-activated.

(7) the return value can indicate the following error:

     inconsistentValue: because the agent is unable to
     remove the row at this time, perhaps because it is in
     use and cannot be de-activated.

(8) the transition to D can fail, e.g., if the values of the
conceptual row are inconsistent, then the error code would
be inconsistentValue.

NOTE: Other processing of (this and other varbinds of) the
set request may result in a response other than noError
being returned, e.g., wrongValue, noCreation, etc.

		  Conceptual Row Creation

There are four potential interactions when creating a
conceptual row:  selecting an instance-identifier which is
not in use; creating the conceptual row; initializing any
objects for which the agent does not supply a default; and,
making the conceptual row available for use by the managed
device.

Interaction 1: Selecting an Instance-Identifier

The algorithm used to select an instance-identifier varies
for each conceptual row.  In some cases, the instance-
identifier is semantically significant, e.g., the
destination address of a route, and a management station
selects the instance-identifier according to the semantics.

In other cases, the instance-identifier is used solely to
distinguish conceptual rows, and a management station
without specific knowledge of the conceptual row might
examine the instances present in order to determine an
unused instance-identifier.  (This approach may be used, but
it is often highly sub-optimal; however, it is also a
questionable practice for a naive management station to
attempt conceptual row creation.)

Alternately, the MIB module which defines the conceptual row
might provide one or more objects which provide assistance
in determining an unused instance-identifier.  For example,
if the conceptual row is indexed by an integer-value, then
an object having an integer-valued SYNTAX clause might be
defined for such a purpose, allowing a management station to
issue a management protocol retrieval operation.  In order
to avoid unnecessary collisions between competing management
stations, `adjacent' retrievals of this object should be
different.

Finally, the management station could select a pseudo-random
number to use as the index.  In the event that this index

was already in use and an inconsistentValue was returned in
response to the management protocol set operation, the
management station should simply select a new pseudo-random
number and retry the operation.

A MIB designer should choose between the two latter
algorithms based on the size of the table (and therefore the
efficiency of each algorithm).  For tables in which a large
number of entries are expected, it is recommended that a MIB
object be defined that returns an acceptable index for
creation.  For tables with small numbers of entries, it is
recommended that the latter pseudo-random index mechanism be
used.

Interaction 2: Creating the Conceptual Row

Once an unused instance-identifier has been selected, the
management station determines if it wishes to create and
activate the conceptual row in one transaction or in a
negotiated set of interactions.

Interaction 2a: Creating and Activating the Conceptual Row

The management station must first determine the column
requirements, i.e., it must determine those columns for
which it must or must not provide values.  Depending on the
complexity of the table and the management station's
knowledge of the agent's capabilities, this determination
can be made locally by the management station.  Alternately,
the management station issues a management protocol get
operation to examine all columns in the conceptual row that
it wishes to create.  In response, for each column, there
are three possible outcomes:

     - a value is returned, indicating that some other
     management station has already created this conceptual
     row.  We return to interaction 1.

     - the exception `noSuchInstance' is returned,
     indicating that the agent implements the object-type
     associated with this column, and that this column in at
     least one conceptual row would be accessible in the MIB
     view used by the retrieval were it to exist. For those
     columns to which the agent provides read-create access,
     the `noSuchInstance' exception tells the management
     station that it should supply a value for this column
     when the conceptual row is to be created.

     - the exception `noSuchObject' is returned, indicating
     that the agent does not implement the object-type
     associated with this column or that there is no
     conceptual row for which this column would be
     accessible in the MIB view used by the retrieval.  As
     such, the management station can not issue any
     management protocol set operations to create an
     instance of this column.

Once the column requirements have been determined, a
management protocol set operation is accordingly issued.
This operation also sets the new instance of the status
column to `createAndGo'.

When the agent processes the set operation, it verifies that
it has sufficient information to make the conceptual row
available for use by the managed device.  The information
available to the agent is provided by two sources:  the
management protocol set operation which creates the
conceptual row, and, implementation-specific defaults
supplied by the agent (note that an agent must provide
implementation-specific defaults for at least those objects
which it implements as read-only).  If there is sufficient
information available, then the conceptual row is created, a
`noError' response is returned, the status column is set to
`active', and no further interactions are necessary (i.e.,
interactions 3 and 4 are skipped).  If there is insufficient
information, then the conceptual row is not created, and the
set operation fails with an error of `inconsistentValue'.
On this error, the management station can issue a management
protocol retrieval operation to determine if this was
because it failed to specify a value for a required column,
or, because the selected instance of the status column
already existed.  In the latter case, we return to
interaction 1.  In the former case, the management station
can re-issue the set operation with the additional
information, or begin interaction 2 again using
`createAndWait' in order to negotiate creation of the
conceptual row.

			 NOTE WELL

     Regardless of the method used to determine the column
     requirements, it is possible that the management
     station might deem a column necessary when, in fact,
     the agent will not allow that particular columnar
     instance to be created or written.  In this case, the
     management protocol set operation will fail with an
     error such as `noCreation' or `notWritable'.  In this
     case, the management station decides whether it needs
     to be able to set a value for that particular columnar
     instance.  If not, the management station re-issues the
     management protocol set operation, but without setting
     a value for that particular columnar instance;
     otherwise, the management station aborts the row
     creation algorithm.

Interaction 2b: Negotiating the Creation of the Conceptual
Row

The management station issues a management protocol set
operation which sets the desired instance of the status
column to `createAndWait'.  If the agent is unwilling to
process a request of this sort, the set operation fails with
an error of `wrongValue'.  (As a consequence, such an agent
must be prepared to accept a single management protocol set
operation, i.e., interaction 2a above, containing all of the
columns indicated by its column requirements.)  Otherwise,
the conceptual row is created, a `noError' response is
returned, and the status column is immediately set to either
`notInService' or `notReady', depending on whether it has
sufficient information to (attempt to) make the conceptual
row available for use by the managed device.  If there is
sufficient information available, then the status column is
set to `notInService'; otherwise, if there is insufficient
information, then the status column is set to `notReady'.
Regardless, we proceed to interaction 3.

Interaction 3: Initializing non-defaulted Objects

The management station must now determine the column
requirements.  It issues a management protocol get operation
to examine all columns in the created conceptual row.  In
the response, for each column, there are three possible
outcomes:

     - a value is returned, indicating that the agent
     implements the object-type associated with this column
     and had sufficient information to provide a value.  For
     those columns to which the agent provides read-create
     access (and for which the agent allows their values to
     be changed after their creation), a value return tells
     the management station that it may issue additional
     management protocol set operations, if it desires, in
     order to change the value associated with this column.

     - the exception `noSuchInstance' is returned,
     indicating that the agent implements the object-type
     associated with this column, and that this column in at
     least one conceptual row would be accessible in the MIB
     view used by the retrieval were it to exist. However,
     the agent does not have sufficient information to
     provide a value, and until a value is provided, the
     conceptual row may not be made available for use by the
     managed device.  For those columns to which the agent
     provides read-create access, the `noSuchInstance'
     exception tells the management station that it must
     issue additional management protocol set operations, in
     order to provide a value associated with this column.

     - the exception `noSuchObject' is returned, indicating
     that the agent does not implement the object-type
     associated with this column or that there is no
     conceptual row for which this column would be
     accessible in the MIB view used by the retrieval.  As
     such, the management station can not issue any
     management protocol set operations to create an
     instance of this column.

If the value associated with the status column is
`notReady', then the management station must first deal with
all `noSuchInstance' columns, if any.  Having done so, the
value of the status column becomes `notInService', and we
proceed to interaction 4.

Interaction 4: Making the Conceptual Row Available

Once the management station is satisfied with the values
associated with the columns of the conceptual row, it issues
a management protocol set operation to set the status column
to `active'.  If the agent has sufficient information to
make the conceptual row available for use by the managed
device, the management protocol set operation succeeds (a
`noError' response is returned).  Otherwise, the management
protocol set operation fails with an error of
`inconsistentValue'.

			 NOTE WELL

     A conceptual row having a status column with value
     `notInService' or `notReady' is unavailable to the
     managed device.  As such, it is possible for the
     managed device to create its own instances during the
     time between the management protocol set operation
     which sets the status column to `createAndWait' and the
     management protocol set operation which sets the status
     column to `active'.  In this case, when the management
     protocol set operation is issued to set the status
     column to `active', the values held in the agent
     supersede those used by the managed device.

If the management station is prevented from setting the
status column to `active' (e.g., due to management station
or network failure) the conceptual row will be left in the
`notInService' or `notReady' state, consuming resources
indefinitely.  The agent must detect conceptual rows that
have been in either state for an abnormally long period of
time and remove them.  It is the responsibility of the
DESCRIPTION clause of the status column to indicate what an
abnormally long period of time would be.  This period of
time should be long enough to allow for human response time
(including `think time') between the creation of the
conceptual row and the setting of the status to `active'.
In the absence of such information in the DESCRIPTION
clause, it is suggested that this period be approximately 5
minutes in length.  This removal action applies not only to
newly-created rows, but also to previously active rows which
are set to, and left in, the notInService state for a
prolonged period exceeding that which is considered normal
for such a conceptual row.

		 Conceptual Row Suspension

When a conceptual row is `active', the management station
may issue a management protocol set operation which sets the
instance of the status column to `notInService'.  If the
agent is unwilling to do so, the set operation fails with an
error of `wrongValue' or `inconsistentValue'.  Otherwise,
the conceptual row is taken out of service, and a `noError'
response is returned.  It is the responsibility of the
DESCRIPTION clause of the status column to indicate under
what circumstances the status column should be taken out of
service (e.g., in order for the value of some other column
of the same conceptual row to be modified).

		  Conceptual Row Deletion

For deletion of conceptual rows, a management protocol set
operation is issued which sets the instance of the status
column to `destroy'.  This request may be made regardless of
the current value of the status column (e.g., it is possible
to delete conceptual rows which are either `notReady',
`notInService' or `active'.)  If the operation succeeds,
then all instances associated with the conceptual row are
immediately removed.

Path expression used to represent a special
schema-instance identifier string.

A schema-instance-identifier value string is an
unrestricted YANG instance-identifier expression.
All the same rules as an instance-identifier apply
except predicates for keys are optional.  If a key
predicate is missing, then the schema-instance-identifier
represents all possible server instances for that key.

XPath string used in the select attribute.

NETCONF Session Id or Zero to indicate none

NETCONF Session Id or Zero to indicate none

NETCONF Session Id

NETCONF Session Id

The Session  Number  convention  is  used  for
numbers  identifying  sessions or saved PATH or
RESV information. It is a number in  the  range
returned  by  a TestAndIncr variable, having no
protocol meaning whatsoever but serving instead
as simple identifier.

The alternative was a very complex instance  or
instance object that became unwieldy.

The value of the C-Type field of a Session ob-
ject,  as  defined  in  the RSVP specification.
This value  determines  the  lengths  of  octet
strings  and use of certain objects such as the
'port' variables. If the C-Type  calls  for  an
IP6  address, one would expect all source, des-



tination, and next/previous hop addresses to be
16  bytes long, and for the ports to be UDP/TCP
port numbers, for example.

XSD 16 bit signed integer.

The mode that a command or prompt should be displayed.
Selects the verbosity level of the output.

An octet string containing administrative
information, preferably in human-readable form.

To facilitate internationalization, this
information is represented using the ISO/IEC
IS 10646-1 character set, encoded as an octet
string using the UTF-8 transformation format
described in [RFC2279].

Since additional code points are added by
amendments to the 10646 standard from time
to time, implementations must be prepared to
encounter any code point from 0x00000000 to
0x7fffffff.  Byte sequences that do not
correspond to the valid UTF-8 encoding of a
code point or are outside this range are
prohibited.

The use of control codes should be avoided.

When it is necessary to represent a newline,
the control code sequence CR LF should be used.

The use of leading or trailing white space should
be avoided.

For code points not directly supported by user
interface hardware or software, an alternative
means of entry and display, such as hexadecimal,
may be provided.

For information encoded in 7-bit US-ASCII,
the UTF-8 encoding is identical to the
US-ASCII encoding.

UTF-8 may require multiple bytes to represent a
single character / code point; thus the length
of this object in octets may be different from
the number of characters encoded.  Similarly,
size constraints refer to the number of encoded
octets, not the number of characters represented
by an encoding.

Note that when this TC is used for an object that
is used or envisioned to be used as an index, then
a SIZE restriction MUST be specified so that the
number of sub-identifiers for any object instance
does not exceed the limit of 128, as defined by
[RFC3416].

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

An SNMP engine's administratively-unique identifier.
Objects of this type are for identification, not for
addressing, even though it is possible that an
address may have been used in the generation of
a specific value.

The value for this object may not be all zeros or
all 'ff'H or the empty (zero length) string.

The initial value for this object may be configured
via an operator console entry or via an algorithmic
function.  In the latter case, the following
example algorithm is recommended.

In cases where there are multiple engines on the
same system, the use of this algorithm is NOT
appropriate, as it would result in all of those
engines ending up with the same ID value.

1) The very first bit is used to indicate how the
   rest of the data is composed.

   0 - as defined by enterprise using former methods
       that existed before SNMPv3. See item 2 below.

   1 - as defined by this architecture, see item 3
       below.

   Note that this allows existing uses of the
   engineID (also known as AgentID [RFC1910]) to
   co-exist with any new uses.

2) The snmpEngineID has a length of 12 octets.

   The first four octets are set to the binary
   equivalent of the agent's SNMP management
   private enterprise number as assigned by the
   Internet Assigned Numbers Authority (IANA).
   For example, if Acme Networks has been assigned
   { enterprises 696 }, the first four octets would
   be assigned '000002b8'H.

   The remaining eight octets are determined via
   one or more enterprise-specific methods. Such
   methods must be designed so as to maximize the
   possibility that the value of this object will
   be unique in the agent's administrative domain.
   For example, it may be the IP address of the SNMP
   entity, or the MAC address of one of the
   interfaces, with each address suitably padded
   with random octets.  If multiple methods are
   defined, then it is recommended that the first
   octet indicate the method being used and the
   remaining octets be a function of the method.

3) The length of the octet string varies.

   The first four octets are set to the binary
   equivalent of the agent's SNMP management
   private enterprise number as assigned by the
   Internet Assigned Numbers Authority (IANA).
   For example, if Acme Networks has been assigned
   { enterprises 696 }, the first four octets would
   be assigned '000002b8'H.

   The very first bit is set to 1. For example, the
   above value for Acme Networks now changes to be
   '800002b8'H.

   The fifth octet indicates how the rest (6th and
   following octets) are formatted. The values for
   the fifth octet are:

     0     - reserved, unused.

     1     - IPv4 address (4 octets)
	     lowest non-special IP address

     2     - IPv6 address (16 octets)
	     lowest non-special IP address

     3     - MAC address (6 octets)
	     lowest IEEE MAC address, canonical
	     order

     4     - Text, administratively assigned
	     Maximum remaining length 27

     5     - Octets, administratively assigned
	     Maximum remaining length 27

     6-127 - reserved, unused

   128-255 - as defined by the enterprise
	     Maximum remaining length 27