List of SMIv2 Textual Conventions
textual-convention-list.txt

The subtree component of a (subtree, list) tuple.  Such a
(subtree, list) tuple defines a set of objects and their
values to be collected as accounting data for a connection.
The subtree specifies a single OBJECT IDENTIFIER value such
that each object in the set is named by the subtree value
appended with a single additional sub-identifier.

The list component of a (subtree, list) tuple.  Such a
(subtree, list) tuple defines a set of objects and their
values to be collected as accounting data for a connection.
The subtree specifies a single OBJECT IDENTIFIER value such
that each object in the set is named by the subtree value
appended with a single additional sub-identifier.  The list
specifies a set of data items, where the presence of an item
in the list indicates that the item is (to be) present in
the data collected for a connection; the absence of an item
from the list indicates that the item is not (to be) present
in the data collected for a connection.  Each data item is
represented by an integer which when appended (as as
additional sub-identifier) to the OBJECT IDENTIFIER value of
the subtree identified by the tuple, is the name of an
object defining that data item (its description and its
syntax).

The list is specified as an OCTET STRING in which each data
item is represented by a single bit, where data items 1
through 8 are represented by the bits in the first octet,
data items 9 through 16 by the bits in the second octet,
etc.  In each octet, the lowest numbered data item is
represented by the most significant bit, and the highest
numbered data item by the least significant bit.  A data
item is present in the list when its bit is set, and absent
when its bit is reset.  If the length of an OCTET STRING
value is too short to represent one or more data items
defined in a subtree, then those data items are absent from
the set identified by the tuple of that subtree and that
OCTET STRING value.

An arbitrary integer value identifying a file into which
accounting data is being collected.

Identifies a transceiver as being either an ATU-C or
an ATU-R.  An ADSL line consists of two transceivers, an ATU-C
and an ATU-R.  Attributes with this syntax reference the two
sides of a line.  Specified as an INTEGER, the two values



are:

 atuc(1)  -- Central office ADSL terminal unit (ATU-C).
 atur(2)  -- Remote ADSL terminal unit (ATU-R).

Identifies the direction of a band as being
either upstream or downstream.  Specified as an INTEGER,
the two values are:
 upstream(1), and
 downstream(2).

A set of ADSL2 line transmission modes, with one bit
per mode.  The notes (F) and (L) denote Full-Rate
and Lite/splitterless, respectively:
   Bit 00 : Regional Std. (ANSI T1.413) (F)
   Bit 01 : Regional Std. (ETSI DTS/TM06006) (F)
   Bit 02 : G.992.1 POTS non-overlapped (F)
   Bit 03 : G.992.1 POTS overlapped (F)
   Bit 04 : G.992.1 ISDN non-overlapped (F)
   Bit 05 : G.992.1 ISDN overlapped (F)
   Bit 06 : G.992.1 TCM-ISDN non-overlapped (F)
   Bit 07 : G.992.1 TCM-ISDN overlapped (F)
   Bit 08 : G.992.2 POTS non-overlapped (L)
   Bit 09 : G.992.2 POTS overlapped (L)
   Bit 10 : G.992.2 with TCM-ISDN non-overlapped (L)
   Bit 11 : G.992.2 with TCM-ISDN overlapped (L)
   Bit 12 : G.992.1 TCM-ISDN symmetric (F) -- not in G.997.1
   Bit 13-17: Reserved
   Bit 18 : G.992.3 POTS non-overlapped (F)
   Bit 19 : G.992.3 POTS overlapped (F)
   Bit 20 : G.992.3 ISDN non-overlapped (F)
   Bit 21 : G.992.3 ISDN overlapped (F)



   Bit 22-23: Reserved
   Bit 24 : G.992.4 POTS non-overlapped (L)
   Bit 25 : G.992.4 POTS overlapped (L)
   Bit 26-27: Reserved
   Bit 28 : G.992.3 Annex I All-Digital non-overlapped (F)
   Bit 29 : G.992.3 Annex I All-Digital overlapped (F)
   Bit 30 : G.992.3 Annex J All-Digital non-overlapped (F)
   Bit 31 : G.992.3 Annex J All-Digital overlapped (F)
   Bit 32 : G.992.4 Annex I All-Digital non-overlapped (L)
   Bit 33 : G.992.4 Annex I All-Digital overlapped (L)
   Bit 34 : G.992.3 Annex L POTS non-overlapped, mode 1,
                            wide U/S (F)
   Bit 35 : G.992.3 Annex L POTS non-overlapped, mode 2,
                            narrow U/S(F)
   Bit 36 : G.992.3 Annex L POTS overlapped, mode 3,
                            wide U/S (F)
   Bit 37 : G.992.3 Annex L POTS overlapped, mode 4,
                            narrow U/S (F)
   Bit 38 : G.992.3 Annex M POTS non-overlapped (F)
   Bit 39 : G.992.3 Annex M POTS overlapped (F)
   Bit 40 : G.992.5 POTS non-overlapped (F)
   Bit 41 : G.992.5 POTS overlapped (F)
   Bit 42 : G.992.5 ISDN non-overlapped (F)
   Bit 43 : G.992.5 ISDN overlapped (F)
   Bit 44-45: Reserved
   Bit 46 : G.992.5 Annex I All-Digital non-overlapped (F)
   Bit 47 : G.992.5 Annex I All-Digital overlapped (F)
   Bit 48 : G.992.5 Annex J All-Digital non-overlapped (F)
   Bit 49 : G.992.5 Annex J All-Digital overlapped (F)
   Bit 50 : G.992.5 Annex M POTS non-overlapped (F)
   Bit 51 : G.992.5 Annex M POTS overlapped (F)
   Bit 52-55: Reserved

Specifies the rate adaptation behavior for the line.
The three possible behaviors are:



 manual(1)    - No Rate-Adaptation.  The initialization
                process attempts to synchronize to a
                specified rate.
 raInit(2)    - Rate-Adaptation during initialization process
                only, which attempts to synchronize to a rate
                between minimum and maximum specified values.
 dynamicRa(3) - Dynamic Rate-Adaptation during initialization
                process as well as during SHOWTIME.

Specifies the result of a full initialization attempt; the
six possible result values are:
 noFail(0)            - Successful initialization.
 configError(1)       - Configuration failure.
 configNotFeasible(2) - Configuration details not supported.
 commFail(3)          - Communication failure.
 noPeerAtu(4)         - Peer ATU not detected.
 otherCause(5)        - Other initialization failure reason.

The values used are as defined in ITU-T G.997.1,
paragraph 7.5.1.3

The ADSL2 management model specified includes an ADSL Mode
attribute that identifies an instance of ADSL Mode-Specific
PSD Configuration object in the ADSL Line Profile.  The
following classes of ADSL operating mode are defined.
The notes (F) and (L) denote Full-Rate and Lite/splitterless
respectively:




+-------+--------------------------------------------------+
| Value |         ADSL operation mode description          |
+-------+--------------------------------------------------+

    1   - The default/generic PSD configuration.  Default
          configuration will be used when no other matching
          mode-specific configuration can be found.
    2   - ADSL family.  The attributes included in the Mode-
          Specific PSD Configuration are irrelevant for
          ITU-T G.992.1 and G.992.2 ADSL modes.  Hence, it
          is possible to map those modes to this generic
          class.
   3-7  - Unused. Reserved for future ITU-T specification.
    8   - G.992.3 POTS non-overlapped (F)
    9   - G.992.3 POTS overlapped (F)
   10   - G.992.3 ISDN non-overlapped (F)
   11   - G.992.3 ISDN overlapped (F)
 12-13  - Unused. Reserved for future ITU-T specification.
   14   - G.992.4 POTS non-overlapped (L)
   15   - G.992.4 POTS overlapped (L)
 16-17  - Unused. Reserved for future ITU-T specification.
   18   - G.992.3 Annex I All-Digital non-overlapped (F)
   19   - G.992.3 Annex I All-Digital overlapped (F)
   20   - G.992.3 Annex J All-Digital non-overlapped (F)
   21   - G.992.3 Annex J All-Digital overlapped (F)
   22   - G.992.4 Annex I All-Digital non-overlapped (L)
   23   - G.992.4 Annex I All-Digital overlapped (L)
   24   - G.992.3 Annex L POTS non-overlapped, mode 1,
          wide U/S (F)
   25   - G.992.3 Annex L POTS non-overlapped, mode 2,
          narrow U/S(F)
   26   - G.992.3 Annex L POTS overlapped, mode 3,
          wide U/S (F)
   27   - G.992.3 Annex L POTS overlapped, mode 4,
          narrow U/S (F)
   28   - G.992.3 Annex M POTS non-overlapped (F)
   29   - G.992.3 Annex M POTS overlapped (F)
   30   - G.992.5 POTS non-overlapped (F)
   31   - G.992.5 POTS overlapped (F)
   32   - G.992.5 ISDN non-overlapped (F)
   33   - G.992.5 ISDN overlapped (F)
 34-35  - Unused. Reserved for future ITU-T specification.
   36   - G.992.5 Annex I All-Digital non-overlapped (F)
   37   - G.992.5 Annex I All-Digital overlapped (F)
   38   - G.992.5 Annex J All-Digital non-overlapped (F)
   39   - G.992.5 Annex J All-Digital overlapped (F)
   40   - G.992.5 Annex M POTS non-overlapped (F)
   41   - G.992.5 Annex M POTS overlapped (F)

Attributes with this syntax uniquely identify each power
management state defined for the ADSL/ADSL2 or ADSL2+ link.
The possible values are:
  l0(1) - L0 - Full power management state.
  l1(2) - L1 - Low power management state (for G.992.2).
  l2(3) - L2 - Low power management state (for G.992.3,
               G.992.4, and G.992.5).
  l3(4) - L3 - Idle power management state.

Attributes with this syntax are configuration parameters
that reference the desired power management state for the
ADSL/ADSL2 or ADSL2+ link:
  l3toL0(0)          - Perform a transition from L3 to L0
                       (Full power management state).
  l0toL2(2)          - Perform a transition from L0 to L2
                       (Low power management state).
  l0orL2toL3(3)      - Perform a transition into L3 (Idle
                       power management state).

The values used are as defined in ITU-T G.997.1,
paragraph 7.3.1.1.3

Attributes with this syntax are configuration parameters
that reference the power modes/states into which the ATU-C or
ATU-R may autonomously transit.

It is a BITS structure that allows control of the following
transit options:
 allowTransitionsToIdle(0)     - XTU may autonomously transit
                                 to idle (L3) state.
 allowTransitionsToLowPower(1) - XTU may autonomously transit
                                 to low-power (L2) state.

Attributes with this syntax are configuration parameters
that control the Loop Diagnostic mode for the ADSL/ADSL2 or
ADSL2+ link.  The possible values are:
  inhibit(0)  - Inhibit Loop Diagnostic mode.
  force(1)    - Force/Initiate Loop Diagnostic mode.

The values used are as defined in ITU-T G.997.1,
paragraph 7.3.1.1.8

Possible failure reasons associated with performing
a Dual Ended Loop Test (DELT) on a DSL line.
Possible values are:
 none(1)         - The default value in case LDSF was never
                   requested for the associated line.
 success(2)      - The recent command completed
                   successfully.
 inProgress(3)   - The Loop Diagnostics process is in
                   progress.
 unsupported(4)  - The NE or the line card doesn't support
                   LDSF.
 cannotRun(5)    - The NE cannot initiate the command, due
                   to a nonspecific reason.
 aborted(6)      - The Loop Diagnostics process aborted.
 failed(7)       - The Loop Diagnostics process failed.
 illegalMode(8)  - The NE cannot initiate the command, due
                   to the specific mode of the relevant
                   line.
 adminUp(9)      - The NE cannot initiate the command, as
                   the relevant line is administratively
                   'Up'.
 tableFull(10)   - The NE cannot initiate the command, due
                   to reaching the maximum number of rows
                   in the results table.
 noResources(11) - The NE cannot initiate the command, due
                   to lack of internal memory resources.

Attributes with this syntax are configuration parameters
that reference the minimum-length impulse noise protection
(INP) in terms of number of symbols.  The possible values are:
noProtection (i.e., INP not required), halfSymbol (i.e., INP
length is 1/2 symbol), and 1-16 symbols in steps of 1 symbol.

Attributes with this syntax are configuration parameters
that reference the maximum Bit Error Rate (BER).
The possible values are:

  eminus3(1)   - Maximum BER=E^-3



  eminus5(2)   - Maximum BER=E^-5
  eminus7(3)   - Maximum BER=E^-7

Each one of the 512 bits in this OCTET
STRING array represents the corresponding bin
in the downstream direction.  A value of one
indicates that the bin is not in use.

Each one of the 64 bits in this OCTET
STRING array represents the corresponding bin
in the upstream direction.  A value of one
indicates that the bin is not in use.

Each one of the 512 bits in this OCTET
STRING array represents the corresponding bin
in the downstream direction.  A value of one
indicates that the bin is part of a notch
filter.

This is a structure that represents up to
32 PSD Mask breakpoints.
Each breakpoint occupies 3 octets: The first
two octets hold the index of the sub-carrier
associated with the breakpoint.  The third octet
holds the PSD reduction at the breakpoint from 0
(0 dBm/Hz) to 255 (-127.5 dBm/Hz) using units of
0.5 dBm/Hz.

This is a structure that represents up to
4 PSD Mask breakpoints.
Each breakpoint occupies 3 octets: The first
two octets hold the index of the sub-carrier
associated with the breakpoint.  The third octet
holds the PSD reduction at the breakpoint from 0
(0 dBm/Hz) to 255 (-127.5 dBm/Hz) using units of
0.5 dBm/Hz.

This is a structure that represents up to
32 transmit spectrum shaping (TSSi) breakpoints.
Each breakpoint occupies 3 octets: The first
two octets hold the index of the sub-carrier
associated with the breakpoint.  The third octet
holds the shaping parameter at the breakpoint.  It
is a value from 0 to 127 (units of -0.5 dB).  The
special value 127 indicates that the sub-carrier
is not transmitted.

This parameter represents the last successfully
transmitted initialization state in the last full
initialization performed on the line.  States are
per the specific xDSL technology and are numbered
from 0 (if G.994.1 is used) or 1 (if G.994.1 is
not used) up to Showtime.

Attributes with this syntax are status parameters
that reflect the failure status for a given endpoint of
ADSL/ADSL2 or ADSL2+ link.

This BITS structure can report the following failures:

 noDefect(0)       - This bit position positively reports
                     that no defect or failure exists.
 lossOfFrame(1)    - Loss of frame synchronization.
 lossOfSignal(2)   - Loss of signal.
 lossOfPower(3)    - Loss of power.  Usually this failure may
                     be reported for ATU-Rs only.
 initFailure(4)    - Recent initialization process failed.
                     Never active on ATU-R.

Attributes with this syntax are status parameters that
reflect the failure status for Transmission Convergence (TC)
layer of a given ATM interface (data path over an ADSL/ADSL2
or ADSL2+ link).

This BITS structure can report the following failures:
 noDefect(0)              - This bit position positively
                            reports that no defect or failure
                            exists.
 noCellDelineation(1)     - The link was successfully



                            initialized, but cell delineation
                            was never acquired on the
                            associated ATM data path.
 lossOfCellDelineation(2) - Loss of cell delineation on the
                            associated ATM data path.

Attributes with this syntax are status parameters that
reflect the failure status for a given PTM interface (packet
data path over an ADSL/ADSL2 or ADSL2+ link).

This BITS structure can report the following failures:
    noDefect(0)     - This bit position positively
                      reports that no defect or failure exists.
    outOfSync(1)    - Out of synchronization.

A set of ADSL line transmission modes, with one bit
per mode.  The notes (F) and (L) denote Full-Rate
and G.Lite respectively:
  Bit 00 : Regional Std. (ANSI T1.413) (F)
  Bit 01 : Regional Std. (ETSI DTS/TM06006) (F)
  Bit 02 : G.992.1 POTS non-overlapped (F)
  Bit 03 : G.992.1 POTS overlapped (F)
  Bit 04 : G.992.1 ISDN non-overlapped (F)
  Bit 05 : G.992.1 ISDN overlapped (F)
  Bit 06 : G.992.1 TCM-ISDN non-overlapped (F)
  Bit 07 : G.992.1 TCM-ISDN overlapped (F)
  Bit 08 : G.992.2 POTS non-overlapped (L)
  Bit 09 : G.992.2 POTS overlapped (L)
  Bit 10 : G.992.2 with TCM-ISDN non-overlapped (L)
  Bit 11 : G.992.2 with TCM-ISDN overlapped (L)
  Bit 12 : G.992.1 TCM-ISDN symmetric (F)

This data type is used as the syntax for the ADSL
Line Code.

A counter associated with interface performance
measurements in a current 1-day (24 hour) measurement
interval.

The value of this counter starts at zero at the
beginning of an interval and is increased when
associated events occur, until the end of the
1-day interval.  At that time the value of the
counter is stored in the previous 1-day history
interval, if available, and the current interval
counter is restarted at zero.

In the case where the agent has no valid data available
for this interval the corresponding object
instance is not available and upon a retrieval
request a corresponding error message shall be
returned to indicate that this instance does
not exist (for example, a noSuchName error for
SNMPv1 and a noSuchInstance for SNMPv2 GET
operation).

A counter associated with interface performance
measurements during the most previous 1-day (24 hour)
measurement interval.  The value of this counter is
equal to the value of the current day counter at
the end of its most recent interval.

In the case where the agent has no valid data available
for this interval the corresponding object
instance is not available and upon a retrieval
request a corresponding error message shall be
returned to indicate that this instance does
not exist (for example, a noSuchName error for
SNMPv1 and a noSuchInstance for SNMPv2 GET
operation).

The number of seconds that have elapsed since
the beginning of the current measurement period.
If, for some reason, such as an adjustment in the
system's time-of-day clock, the current interval
exceeds the maximum value, the agent will return
the maximum value.

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

This data type is used to model the error status of the
constituent MO instances.  The error status for a
constituent MO instance is given in terms of two elements:
  o The moIndex, which indicates the position of the MO
    instance (starting at 1) in the value of the aggregated
    MO instance.
  o The moError, which indicates the error that was
    encountered in fetching that MO instance.
The syntax in ASN.1 Notation will be
ErrorStatus :: = SEQUENCE {
   moIndex  Integer32,
   moError  SnmpPduErrorStatus
}
AggrMOErrorStatus ::= SEQUENCE OF {
   ErrorStatus
}
Note1: The command responder will supply values for all
       constituent MO instances, in the same order in
       which the MO instances are specified for the AgMO.
       If an error is encountered for an MO instance, then
       the corresponding value will have an ASN.1 value NULL,
       and an error will be flagged in the corresponding
       AggrMOErrorStatus object.
       Only MOs for which errors have been encountered will
       have their corresponding moIndex and moError values
       set.
Note2: The error code for the component MO instances will be
       in accordance with the SnmpPduErrorStatus TC defined
       in the DISMAN-SCHEDULE-MIB [RFC3231].
Note3: The command generator will need to know
       constituent MO instances and their order to correctly
       interpret AggrMOErrorStatus.

This data type is used to model the aggregate
MOs.  It will have a format dependent on the constituent
MOs, a sequence of values.  The syntax in ASN.1 Notation will
be
MOValue :: = SEQUENCE {
     value ObjectSyntax
}
where 'value' is the value of a constituent MO instance.
AggrMOValue :: = SEQUENCE OF {
    MOValue
}

Note: The command generator will need to know the
constituent MO instances and their order to
correctly interpret AggrMOValue.

This data type is used to model the compressed
aggregate MOs.

A unique identifier for this resource.

The type of the resource can be determined by looking
at the OID that describes the resource.

Resources must be identified in a consistent manner.
For example, if this resource is an interface, this
object MUST point to an ifIndex and if this resource
is a physical entity [RFC2737], then this MUST point
to an entPhysicalDescr, given that entPhysicalIndex
is not accessible.  In general, the value is the
name of the instance of the first accessible columnar
object in the conceptual row of a table that is
meaningful for this resource type, which SHOULD
be defined in an IETF standard MIB.

An SNMP Engine ID or a zero-length string.  The
instantiation of this textual convention will provide
guidance on when this will be an SNMP Engine ID and
when it will be a zero lengths string

A locally arbitrary unique identifier associated with an
application or application verb.

All objects of type AppLocalIndex are assigned by the agent
out of a common number space. In other words, AppLocalIndex
values assigned to entries in one table must not overlap with
AppLocalIndex values assigned to entries in another
table. Further, every protocolDirLocalIndex value registered
by the agent automatically assigns the same value out of the



AppLocalIndex number space.

For example, if the protocolDirLocalIndex values { 1, 3, 5, 7 }
have been assigned, and the apmHttpFilterAppLocalIndex values
{ 6, 8, 9 } have been assigned:

    - Assignment of new AppLocalIndex values must not use the
      values { 1, 3, 5, 6, 7, 8, 9 }.
    - AppLocalIndex values { 1, 3, 5, 7 } are automatically
      assigned and are associated with the identical value of
      protocolDirLocalIndex. In particular, an entry in the
      apmAppDirTable indexed by a value provides further
      information about a protocol indexed by the same value
      in the protocolDirTable of RMON2.

The value for each supported application must remain constant
at least from one re-initialization of the entity's network
management system to the next re-initialization, except that
if an application is deleted and re-created, it must be
re-created with a new value that has not been used since the
last re-initialization.

The specific value is meaningful only within a given SNMP
entity. An AppLocalIndex value must not be re-used until the
next agent restart.

A network level address whose semantics and encoding are
specified by an associated protocolDirLocalIndex
value. Objects of this type must specify which
protocolDirLocalIndex value is used. This value is encoded
according to the encoding rules for the identified
protocolDirectory entry.

For example, if the associated protocolDirLocalIndex indicates
an encapsulation of ip, this object is encoded as a length
octet of 4, followed by the 4 octets of the ip address,
in network byte order.

Objects of this type may allow this value to be the zero
length string. If so, they must identify they meaning of this
value.

Identifies the source of the data that the associated
function is configured to analyze. This source can be any
interface on this device.

In order to identify a particular interface, this
object shall identify the instance of the ifIndex
object, defined in [4], for the desired interface.

For example, if an entry were to receive data from
interface #1, this object would be set to ifIndex.1.

If the source of the data isn't an interface or cannot be
localized to an interface, this object would be set to 0.0

A long-lived unique ID assigned to an end-system. This ID is
assigned by the agent using an implementation-specific
algorithm.

Because a client machine may be assigned multiple addresses
over any time period it can be difficult to attribute
behavior to a particular client based solely on its
address. A ClientID may be assigned to provide a more
stable handle for referencing that client. The entity that
assigns the ClientID may use various implementation
techniques to keep track of a client but if the assigning
entity is unable to track client address mappings, it may map
client identifiers to client addresses rather than to
distinct client machines.

This is named ClientID because it helps to solve a problem
seen in network clients (servers usually have well-known,
long-lived addresses). However, ClientID's may be assigned to
any end-system regardless of its role on the network.

Specifies one of 4 different techniques for aggregating
transactions.

The metrics for a single transaction are the responsiveness of
the transaction and whether the transaction succeeded (a
boolean). When such metrics are aggregated in this MIB Module,
these metrics are replaced by averages and distributions of
responsiveness and availability. The metrics describing
aggregates are constant no matter which type of aggregation is
being performed. These metrics may be found in the
apmReportTable.

The flows(1) aggregation is the simplest. All transactions
that share common application/server/client 3-tuples are
aggregated together, resulting in a set of metrics for all
such unique 3-tuples.

The clients(2) aggregation results in somewhat more
aggregation (i.e., fewer resulting records). All transactions
that share common application/client tuples are aggregated
together, resulting in a set of metrics for all such unique
tuples.

The servers(3) aggregation usually results in still more
aggregation (i.e., fewer resulting records). All transactions
that share common application/server tuples are aggregated
together, resulting in a set of metrics for all such unique
tuples.

The applications(4) aggregation results in the most
aggregation (i.e., the fewest resulting records). All
transactions that share a common application are aggregated
together, resulting in a set of metrics for all such unique
applications.

Note that it is not meaningful to aggregate applications, as
different applications have widely varying characteristics. As a
result, this set of aggregations is complete.

To facilitate their display by a Management Station, sense
data objects in the MIB are represented as DisplayStrings of
size 8.  Eight '0' characters indicates that no sense data
identifying an SNA error condition is available.

A non-negative 64-bit bit integer, without counter
semantics.

Denotes a transport service address.

For snmpUDPDomain, an ApplTAddress is 6 octets long,
the initial 4 octets containing the IP-address in
network-byte order and the last 2 containing the UDP
port in network-byte order.  Consult 'Transport Mappings
for Version 2 of the Simple Network Management Protocol
(SNMPv2)' for further information on snmpUDPDomain.

An SNA Node Identification consists of two parts, which
together comprise four bytes of hexadecimal data.  In SNA the
Node Identification is transported in bytes 2-5 of the XID.

The block number is the first three digits of the Node
Identification.  These 3 hexadecimal digits identify the
product.

The ID number is the last 5 digits of the Node Identification.
These 5 hexadecimal digits are administratively defined and
combined with the 3-digit block number form the 8-digit Node
Identification.  A unique value is required for connections to
SNA subarea.  In some implementations, the value 'bbb00000'
(where 'bbb' represents a 3-digit block number) is returned to
mean that the ID number is not unique on this node.

An SNA Node Identification is represented as eight
ASCII-encoded hexadecimal digits, using the characters '0' -
'9' and 'A' - 'F'.

A fully qualified SNA control point name, consisting of a 1 to
8 character network identifier (NetId), a period ('.'), and a 1
to 8 character control point name (CpName).

The NetId and CpName are constructed from the uppercase letters
'A' - 'Z' and the numerics '0' - '9', all encoded in ASCII,
with the restriction that the first character of each must be
a letter.  Trailing blanks are not allowed.

Earlier versions of SNA permitted three additional characters
in NetIds and CpNames:  '#', '@', and '$'.  While this use of
these characters has been retired, a Management Station should
still accept them for backward compatibility.

An SNA class-of-service (COS) name, ranging from 1 to 8
ASCII characters.  COS names take one of two forms:

   -  a user-defined COS name is constructed from the uppercase
      letters 'A' - 'Z' and the numerics '0' - '9', with the
      restriction that the first character of the name must be
      a letter.
   -  an SNA-defined user-session COS name begins with the
      character '#', which is followed by up to seven
      additional characters from the set of uppercase letters
      and numerics.

Trailing blanks are not allowed in either form of COS name.

A zero-length string indicates that a COS name is not
available.

An SNA mode name, ranging from 1 to 8 ASCII characters.
Mode names take one of two forms:

   -  a user-defined mode name is constructed from the
      uppercase letters 'A' - 'Z' and the numerics '0' - '9',
      with the restriction that the first character of the name
      must be a letter.
   -  an SNA-defined user-session mode name begins with the
      character '#', which is followed by up to seven
      additional characters from the set of uppercase letters
      and numerics.

Trailing blanks are not allowed in either form of mode name,
with the single exception of the all-blank mode name, where
a string consisting of 8 blanks is returned.

A zero-length string indicates that a mode name is not
available.

To facilitate their display by a Management Station, sense
data objects in the MIB are represented as OCTET STRINGS
containing eight ASCII characters.  Eight '0' characters
indicates that no sense data identifying an SNA error
condition is available.

An SNA sense data is represented as eight hexadecimal digits,
using the characters '0' - '9' and 'A' - 'F'.

DLC address of a port or link station, represented as an
OCTET STRING containing 0 to 64 ASCII characters.
A Management Station should use a value of this type only
for display.  The 'real' DLC address, i.e., the sequence of
bytes that flow in the DLC header, is often available in a
DLC-specific MIB.

The zero-length string indicates that the DLC address in
question is not known to the agent.

An object providing global statistics for the entire APPN
node.  A Management Station can detect discontinuities in this
counter by monitoring the appnNodeCounterDisconTime object.

An object providing statistics for an APPN port.  A
Management Station can detect discontinuities in this counter
by monitoring the appnPortCounterDisconTime object.

An object providing statistics for an APPN link station.  A
Management Station can detect discontinuities in this counter
by monitoring the appnLsCounterDisconTime object.

Number of days before deletion of this entry from the topology
database.  Range is 0-15.  A value of 0 indicates that the
entry is either in the process of being deleted, or is being
marked for deletion at the next garbage collection cycle.

DLC-specific data related to a connection network transmission
group.  For other TGs, a zero-length string is returned.

Examples of the type of data returned by an object with this
syntax include the following:

      Token-Ring      - MAC/SAP
      X.25 Switched   - dial digits
      X.21 Switched   - dial digits
      Circuit Switch  - dial digits
This MIB does not specify formats for these or any other types
of DLC-specific data.  Formats may, however, be specified in
documents related to a particular DLC.

The contents of an object with this syntax correspond to the
contents of the DLC-specific subfields of cv46, documented in
(6).

A value representing the effective capacity of a transmission
group.  This is an administratively assigned value derived from
the link bandwidth and maximum load factor.  It is encoded in
the same way as byte 7 of cv47, and represents a floating-point
number in units of 300 bits per second.

A value representing the level of security on a transmission
group.  A class of service definition includes an indication of
the acceptable TG security value(s) for that class of service.

The following seven values are defined:

  nonsecure(1) -
                    (X'01'):  none of the values listed below;
                    for example, satellite-connected or
                    located in a nonsecure country
  publicSwitchedNetwork(32) -
                    (X'20'):  public switched network; secure
                    in the sense that there is no
                    predetermined route that traffic will take
  undergroundCable(64) -
                    (X'40'):  underground cable; located in a
                    secure country (as determined by the
                    network administrator)
  secureConduit(96) -
                    (X'60'):  secure conduit, not guarded; for
                    example, pressurized pipe
  guardedConduit(128) -
                    (X'80'):  guarded conduit; protected
                    against physical tapping
  encrypted(160) -
                    (X'A0'):  link-level encryption is provided
  guardedRadiation(192) -
                    (X'C0'):  guarded conduit containing the
                    transmission medium; protected against
                    physical and radiation tapping

Relative amount of time that it takes for a signal to travel
the length of a logical link.  This time is represented in
microseconds, using the same encoding scheme used in cv47 in a
topology update.  Some of the more common values, along with
their encoded hex values, are:

           minimum(0),                 X'00'
           negligible(384),            X'4C'
           terrestrial(9216),          X'71'
           packet(147456),             X'91'
           long(294912),               X'99'
           maximum(2013265920)         X'FF'

This Textual Convention describes an object that stores
a SONET K1 and K2 byte APS protocol field.

K1 is located in the first octet, K2 is located in
the second octet. Bits are numbered from left to right.

Bits 1-4 of the K1 byte indicate a request.

1111  Lockout of Protection
1110  Forced Switch
1101  SF - High Priority
1100  SF - Low Priority
1011  SD - High Priority
1010  SD - Low Priority
1001  not used
1000  Manual Switch
0111  not used
0110  Wait-to-Restore
0101  not used
0100  Exercise
0011  not used
0010  Reverse Request
0001  Do Not Revert
0000  No Request

Bits 5-8 of the K1 byte indicate the channel associated with
the request defined in bits 1-4.

0000 is the Null channel.





1-14 are working channels.
15   is the extra traffic channel

Bits 1-4 of the K2 byte indicate a channel. The channel is
defined with the same syntax as K1 Bits 5-8.

Bit 5 of the K2 byte indicates the
architecture.

0 if the architecture is 1+1
1 if the architecture is 1:n

Bits 6-8 of the K2 byte indicates the mode.

000 - 011 are reserved for future use
100  indicates the mode is unidirectional
101  indicates the mode is bidirectional
110  RDI-L
111  AIS-L

An APS switch command allows a user to perform protection
switch actions.

If the APS switch command cannot be executed because an
equal or higher priority request is in effect, an
inconsistentValue error is returned.

The Switch command values are:

noCmd

This value should be returned by a read request when no switch
command has been written to the object in question since
initialization. This value may not be used in a write
operation.  If noCmd is used in a write operation a wrongValue
error is returned.







clear

Clears all of the switch commands listed below for the
specified channel.

lockoutOfProtection

Prevents any of the working channels from switching to the
protection line. The specified channel should be the protection
channel, otherwise an inconsistentValue error is returned.

forcedSwitchWorkToProtect

Switches the specified working channel to the protection line.
If the protection channel is specified an inconsistentValue
error is returned.

forcedSwitchProtectToWork

Switches the working channel back from the protection
line to the working line. The specified channel should be
the protection channel, otherwise an inconsistentValue
error is returned.

manualSwitchWorkToProtect

Switches the specified working channel to the protection line.
If the protection channel is specified an inconsistentValue
error is returned.

manualSwitchProtectToWork

Switches the working channel back from the protection
line to the working line. The specified channel should be
the protection channel, otherwise an inconsistentValue
error is returned.

exercise

Exercises the protocol for a protection switch of the specified
channel by issuing an Exercise request for that channel and
checking the response on the APS channel.

An APS control command applies only to LTE that support the
1:n architecture and performs the following actions.

The Control command values are:

noCmd

This value should be returned by a read request when no control
command has been written to the object in question since
initialization. This value may not be used in a write
operation.  If noCmd is used in a write operation a wrongValue
error is returned.

lockoutWorkingChannel

Prevents the specified working channel from switching to the
protection line. If the protection line is specified an
inconsistentValue error is returned.

clearLockoutWorkingChannel

Clears the lockout a working channel command for the channel
specified. If the protection line is specified an
inconsistentValue error is returned.

This TC can take any value of IANAItuProbableCause or 0.
IANAItuProbableCause is defined in the IANA-ITU-ALARM-TC
module, which is maintained at the IANA web site and
published in the Alarm MIB document (see RFC 3877).

An ATM address. The semantics are implied by
the length. The address types are: - no
address (0 octets) - E.164 (8 octets) - NSAP
(20 octets) In addition, when subaddresses
are used the AtmAddr may represent the
concatenation of address and subaddress. The
associated address types are: - E.164, E.164
(16 octets) - E.164, NSAP (28 octets) - NSAP,
NSAP (40 octets) Address lengths other than
defined in this definition imply address
types defined elsewhere.  Note: The E.164
address is encoded in BCD format.

The type of topology of a connection (point-
to-point, point-to-multipoint). In the case
of point-to-multipoint, the orientation of
this VPL or VCL in the connection.
On a host:
- p2mpRoot indicates that the host
  is the root of the p2mp connection.
- p2mpLeaf indicates that the host
  is a leaf of the p2mp connection.
On a switch interface:
- p2mpRoot indicates that cells received
  by the switching fabric from the interface
  are from the root of the p2mp connection.
- p2mpLeaf indicates that cells transmitted
  to the interface from the switching fabric
  are to the leaf of the p2mp connection.

The type of call control used for an ATM
connection at a particular interface. The use
is as follows:
   pvc(1)
      Virtual link of a PVC. Should not be
      used for an PVC/SVC (i.e., Soft PVC)
      crossconnect.
   svcIncoming(2)
      Virtual link established after a
      received signaling request to setup
      an SVC.
   svcOutgoing(3)
      Virtual link established after a
      transmitted or forwarded signaling
      request to setup an SVC.
   spvcInitiator(4)
      Virtual link at the PVC side of an
      SVC/PVC crossconnect, where the
      switch is the initiator of the Soft PVC
      setup.
   spvcTarget(5)
      Virtual link at the PVC side of an
      SVC/PVC crossconnect, where the
      switch is the target of the Soft PVC
      setup.

For PVCs, a pvc virtual link is always cross-
connected to a pvc virtual link.

For SVCs, an svcIncoming virtual link is always cross-
connected to an svcOutgoing virtual link.

For Soft PVCs, an spvcInitiator is either cross-connected to
an svcOutgoing or an spvcTarget, and an spvcTarget is either
cross-connected to an svcIncoming or an spvcInitiator.

A network prefix used for ILMI address
registration.  In the case of ATM endsystem
addresses (AESAs), the network prefix is the first
13 octets of the address which includes the AFI,
IDI, and HO-DSP fields.  In the case of native
E.164 addresses, the network prefix is the entire
E.164 address encoded in 8 octets, as if it were
an E.164 IDP in an ATM endsystem address
structure.

The connection setup procedures used for the
identified interface.

Other: Connection setup procedures other than
   those listed below.
Auto-configuration:
   Indicates that the connection setup
   procedures are to be determined dynamically,
   or that determination has not yet been
   completed. One such mechanism is via ATM
   Forum ILMI auto-configuration procedures.

ITU-T DSS2:
-  ITU-T Recommendation Q.2931, Broadband
   Integrated Service Digital Network (B-ISDN)
   Digital Subscriber Signalling System No.2
   (DSS2) User-Network Interface (UNI) Layer 3
   Specification for Basic Call/Connection
   Control (September 1994)
-  ITU-T Draft Recommendation Q.2961,
   B-ISDN DSS 2 Support of Additional Traffic
   Parameters (May 1995)

-  ITU-T Draft Recommendation Q.2971,
   B-ISDN DSS 2 User Network Interface Layer 3
   Specification for Point-to-multipoint
   Call/connection Control (May 1995)

ATM Forum UNI 3.0:
   ATM Forum, ATM User-Network Interface,
   Version 3.0 (UNI 3.0) Specification,
   (1994).

ATM Forum UNI 3.1:
   ATM Forum, ATM User-Network Interface,
   Version 3.1 (UNI 3.1) Specification,
   (November 1994).

ATM Forum UNI Signalling 4.0:
   ATM Forum, ATM User-Network Interface (UNI)
   Signalling Specification Version 4.0,
   af-sig-0061.000 (June 1996).

ATM Forum IISP (based on UNI 3.0 or UNI 3.1) :
   Interim Inter-switch Signaling Protocol
   (IISP) Specification, Version 1.0,
   af-pnni-0026.000, (December 1994).

ATM Forum PNNI 1.0 :
   ATM Forum, Private Network-Network Interface
   Specification, Version 1.0, af-pnni-0055.000,
   (March 1996).
ATM Forum B-ICI:
   ATM Forum, B-ICI Specification, Version 2.0,
   af-bici-0013.002, (November 1995).

ATM Forum UNI PVC Only:
   An ATM Forum compliant UNI with the
   signalling disabled.
ATM Forum NNI PVC Only:
   An ATM Forum compliant NNI with the
   signalling disabled.

The service category for a connection.

The value of this object identifies a row in the
atmSigDescrParamTable. The value 0 signifies that
none of the signalling parameters defined in the
atmSigDescrParamTable are applicable.

The value of this object identifies a row in the
atmTrafficDescrParamTable.  The value 0 signifies
that no row has been identified.

The VCI value for a VCL. The maximum VCI value
cannot exceed the value allowable by
atmInterfaceMaxVciBits defined in ATM-MIB.

The VPI value for a VPL or VCL. The value VPI=0
is only allowed for a VCL. For ATM UNIs supporting
VPCs the VPI value ranges from 0 to 255.  The VPI
value 0 is supported for ATM UNIs conforming to
the ATM Forum UNI 4.0 Annex 8 (Virtual UNIs)
specification. For ATM UNIs supporting VCCs the
VPI value ranges from 0 to 255.  For ATM NNIs the
VPI value ranges from 0 to 4095.  The maximum VPI
value cannot exceed the value allowable by
atmInterfaceMaxVpiBits defined in ATM-MIB.

The value determines the desired administrative
status of a virtual link or cross-connect. The up
and down states indicate that the traffic flow is
enabled or disabled respectively on the virtual
link or cross-connect.

The value of MIB II's sysUpTime at the time a
virtual link or cross-connect entered its current
operational state. If the current state was
entered prior to the last re-initialization of the
agent then this object contains a zero value.

The value determines the operational status of a
virtual link or cross-connect. The up and down
states indicate that the traffic flow is enabled
or disabled respectively on the virtual link or
cross-connect. The unknown state indicates that
the state of it cannot be determined. The state
will be down or unknown if the supporting ATM
interface(s) is down or unknown respectively.

Operations supported by a heating and cooling system.
A reference to underlying general systems would go here.

The Bridge-Identifier, as used in the Spanning Tree
Protocol, to uniquely identify a bridge.  Its first two
octets (in network byte order) contain a priority value,
and its last 6 octets contain the MAC address used to
refer to a bridge in a unique fashion (typically, the
numerically smallest MAC address of all ports on the
bridge).

A Spanning Tree Protocol (STP) timer in units of 1/100
seconds.  Several objects in this MIB module represent
values of timers used by the Spanning Tree Protocol.
In this MIB, these timers have values in units of
hundredths of a second (i.e., 1/100 secs).

These timers, when stored in a Spanning Tree Protocol's
BPDU, are in units of 1/256 seconds.  Note, however, that
802.1D-1998 specifies a settable granularity of no more
than one second for these timers.  To avoid ambiguity,
a conversion algorithm is defined below for converting
between the different units, which ensures a timer's
value is not distorted by multiple conversions.

To convert a Timeout value into a value in units of
1/256 seconds, the following algorithm should be used:

    b = floor( (n * 256) / 100)

where:
    floor   =  quotient [ignore remainder]
    n is the value in 1/100 second units
    b is the value in 1/256 second units

To convert the value from 1/256 second units back to
1/100 seconds, the following algorithm should be used:

    n = ceiling( (b * 100) / 256)

where:
    ceiling = quotient [if remainder is 0], or
              quotient + 1 [if remainder is nonzero]
    n is the value in 1/100 second units



    b is the value in 1/256 second units

Note: it is important that the arithmetic operations are
done in the order specified (i.e., multiply first,
divide second).

Represents the unique identifier of a WTP profile.

Represents the unique identifier of a WTP instance.
As usual, the Base MAC address of the WTP is used.

Represents the unique identifier of a station instance.
As usual, the MAC address of the station is used.

Represents the unique identifier of a radio on a WTP.

Represents the tunneling modes of operation that are
supported by a WTP.
The WTP MAY support more than one option, represented by
the bit field below:
  localBridging(0) - Local bridging mode
  dot3Tunnel(1)    - 802.3 frame tunnel mode
  nativeTunnel(2)  - Native frame tunnel mode

Represents the MAC mode of operation supported by a WTP.
The following enumerated values are supported:
  localMAC(0) - Local-MAC mode
  splitMAC(1) - Split-MAC mode
  both(2)     - Both Local-MAC and Split-MAC
Note that the CAPWAP field [RFC5415] modeled by this
object takes zero as starting value; this MIB object
follows that rule.

Represents the channel type for CAPWAP protocol.
The following enumerated values are supported:
  data(1)    - Data channel
  control(2) - Control channel

Represents the authentication credential type for a WTP.
The following enumerated values are supported:
  other(1) - Other method, for example, vendor specific
  clear(2) - Clear text and no authentication
  x509(3)  - X.509 certificate authentication
  psk(4)   - Pre-Shared secret authentication
As a mandatory requirement, CAPWAP control channel
authentication SHOULD use DTLS, either by certificate or
PSK.  For data channel authentication, DTLS is optional.

Represents the unique identifier of a Wireless Local Area
Network (WLAN).

Represents the unique identifier of a WLAN profile.

A unique value, greater than zero, for each
character port 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.

In a system where the character ports are attached
to hardware represented by an ifIndex, it is
conventional, but not required, to make the
character port index equal to the corresponding
ifIndex.

The direction of data flow thru a circuit.

transmit(1) - Only transmitted data
receive(2)  - Only received data
both(3)     - Both transmitted and received data.

A value indicating the state of a COPS client.

A value indicating how a COPS server entry came into existence.

A value describing a COPS protocol error. Codes are identical
to those used by the COPS protocol itself.

A value indicating a TCP protocol port number.

A value indicating a type of security authentication mechanism.

Represents a Counter32-like value that starts at zero,
does not decrease, and does not wrap. This may be used
only in situations where wrapping is not possible or
extremely unlikely. Should such a counter overflow,
it locks at the maxium value of 4,294,967,295.

The primary use of this type of counter is situations
where a counter value is to be recorded as history
and is thus no longer subject to reading for changing
values.

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

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.

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.

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.

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

Used to report the result of an operation:

responseReceived(1) - Operation is completed successfully.
unknown(2) - Operation failed due to unknown error.
internalError(3) - An implementation detected an error
     in its own processing that caused an operation
     to fail.
requestTimedOut(4) - Operation failed to receive a
     valid reply within the time limit imposed on it.
unknownDestinationAddress(5) - Invalid destination
     address.
noRouteToTarget(6) - Could not find a route to target.
interfaceInactiveToTarget(7) - The interface to be
     used in sending a probe is inactive, and an
     alternate route does not exist.
arpFailure(8) - Unable to resolve a target address to a
     media-specific address.
maxConcurrentLimitReached(9) - The maximum number of
     concurrent active operations would have been exceeded
     if the corresponding operation was allowed.
unableToResolveDnsName(10) - The DNS name specified was
     unable to be mapped to an IP address.
invalidHostAddress(11) - The IP address for a host
     has been determined to be invalid.  Examples of this
     are broadcast or multicast addresses.

This TC enumerates the SNMPv1 and SNMPv2 PDU error status
codes as defined in RFC 1157 and RFC 1905.  It also adds a
pseudo error status code `noResponse' which indicates a
timeout condition.

Represents a single qualified NetBIOS name, which can include
`don't care' and `wildcard' characters to represent a number
of real NetBIOS names.  If an individual character position in
the qualified name contains a `?', the corresponding character
position in a real NetBIOS name is a `don't care'.  If the
qualified name ends in `*', the remainder of a real NetBIOS
name is a `don't care'. `*' is only considered a wildcard if it
appears at the end of a name.

Represents an 802 MAC address represented in
non-canonical format.  That is, the most significant
bit will be transmitted first.  If this information
is not available, the value is a zero length string.

Denotes a transport service address.
For dlswTCPDomain, a TAddress is 4 octets long,
containing the IP-address in network-byte order.

Representing the location of an end station related
to the managed DLSw node.

Representing the type of DLC of an end station, if
applicable.

The largest size of the INFO field (including DLC header,
not including any MAC-level or framing octets).
64 valid values as defined by the IEEE 802.1D
Addendum are acceptable.

Represents the IP address of a DLSw which uses
TCP as a transport protocol.

A DNS name is a sequence of labels.  When DNS names are
displayed, the boundaries between labels are typically
indicated by dots (e.g. `Acme' and `COM' are labels in
the name `Acme.COM').  In the DNS protocol, however, no
such separators are needed because each label is encoded
as a length octet followed by the indicated number of
octets of label.  For example, `Acme.COM' is encoded as
the octet sequence { 4, 'A', 'c', 'm', 'e', 3, 'C', 'O',
'M', 0 } (the final 0 is the length of the name of the
root domain, which appears implicitly at the end of any
DNS name).  This MIB uses the same encoding as the DNS
protocol.

A DnsName must always be a fully qualified name.  It is
an error to encode a relative domain name as a DnsName
without first making it a fully qualified name.

This textual convention is like a DnsName, but is used
as an index componant in tables.  Alphabetic characters
in names of this type are restricted to uppercase: the
characters 'a' through 'z' are mapped to the characters
'A' through 'Z'.  This restriction is intended to make
the lexical ordering imposed by SNMP useful when applied
to DNS names.

Note that it is theoretically possible for a valid DNS
name to exceed the allowed length of an SNMP object
identifer, and thus be impossible to represent in tables
in this MIB that are indexed by DNS name.  Sampling of
DNS names in current use on the Internet suggests that
this limit does not pose a serious problem in practice.

This data type is used to represent the class values
which appear in Resource Records in the DNS.  A 16-bit
unsigned integer is used to allow room for new classes
of records to be defined.  Existing standard classes are
listed in the DNS specifications.

This data type is used to represent the type values
which appear in Resource Records in the DNS.  A 16-bit
unsigned integer is used to allow room for new record
types to be defined.  Existing standard types are listed
in the DNS specifications.

This data type is used to represent the QClass values
which appear in Resource Records in the DNS.  A 16-bit
unsigned integer is used to allow room for new QClass
records to be defined.  Existing standard QClasses are
listed in the DNS specification.

This data type is used to represent the QType values
which appear in Resource Records in the DNS.  A 16-bit
unsigned integer is used to allow room for new QType
records to be defined.  Existing standard QTypes are
listed in the DNS specification.

DnsTime values are 32-bit unsigned integers which
measure time in seconds.

This textual convention is used to represent the DNS
OPCODE values used in the header section of DNS
messages.  Existing standard OPCODE values are listed in
the DNS specifications.

This data type is used to represent the DNS RCODE value
in DNS response messages.  Existing standard RCODE
values are listed in the DNS specifications.

An X509 digital certificate encoded as an ASN.1 DER
object.

Security Association identifier (SAID).

Security Association identifier (SAID).  The value
zero indicates that the SAID is yet to be determined.

The type of security association (SA).
The values of the named-numbers are associated
with the BPKM SA-Type attributes:
'primary' corresponds to code '1', 'static' to code '2',



and 'dynamic' to code '3'.
The 'none' value must only be used if the SA type has yet
to be determined.

The list of data encryption algorithms defined for
the DOCSIS interface in the BPKM cryptographic-suite
parameter.  The value 'none' indicates that the SAID
being referenced has no data encryption.

The list of data integrity algorithms defined for the
DOCSIS interface in the BPKM cryptographic-suite parameter.
The value 'none' indicates that no data integrity is used for
the SAID being referenced.

Indicates a direction on an RF MAC interface.

The value downstream(1) is from Cable Modem
Termination System to Cable Modem.

The value upstream(2) is from Cable Modem to
Cable Modem Termination System.

The rate of traffic in unit of bits per second.
Used to specify traffic rate for QOS.

The scheduling service provided by a CMTS for an
upstream Service Flow.  If the parameter is omitted
from an upstream QOS Parameter Set, this object
takes the value of bestEffort (2).  This parameter
must be reported as undefined (1) for downstream
QOS Parameter Sets.

This data type represents power levels that are normally
expressed in dBmV.  Units are in tenths of a dBmV;
for example, 5.1 dBmV will be represented as 51.

This data type represents power levels that are normally
expressed in dB.  Units are in tenths of a dB;
for example, 5.1 dB will be represented as 51.

Indicates the DOCSIS Radio Frequency specification being
referenced.
'docsis10' indicates DOCSIS 1.0.
'docsis11' indicates DOCSIS 1.1.
'docsis20' indicates DOCSIS 2.0.

Indicates the referenced quality-of-service
level.
'docsis10 refers to DOCSIS 1.0 Class of
Service queuing services, and 'docsis11' refers
to DOCSIS 1.1 Quality of Service.

Indicates the DOCSIS Upstream Channel Type.
'unknown' means information not available.
'tdma' is related to TDMA, Time Division
Multiple Access; 'atdma' is related to A-TDMA,
Advanced Time Division Multiple Access,
'scdma' is related to S-CDMA, Synchronous
Code Division Multiple Access.
'tdmaAndAtdma is related to simultaneous support of
TDMA and A-TDMA modes.

This data type represents the equalizer data
as measured at the receiver interface.
The format of the equalizer follows the structure of the
Transmit Equalization Adjust RNG-RSP TLV of DOCSIS RFI
v2.0 :
1 byte Main tap location 1..(n + m)
1 byte Number of forward taps per symbol
1 byte Number of forward taps: n
1 byte Number of reverse taps: m

Following are the equalizer coefficients:
First, forward taps coefficients:
2 bytes F1 (real),  2 bytes  F1 (imag)



...
2 bytes Fn (real),  2 bytes  Fn (imag)

Then, reverse taps coefficients:
2 bytes D1 (real),  2 bytes  D1 (imag)
...

2 bytes Dm (real),  2 bytes  Dm (imag)

The equalizer coefficients are considered signed 16-bit
integers in the range from -32768 (0x8000) to 32767
(0x7FFF).

DOCSIS specifications require up to a maximum of
64 equalizer taps (n + m); therefore, this object size
 can get up 260 bytes (4 + 4x64).
The minimum object size (other than zero) for a t-spaced
tap with a minimum of 8 symbols will be 36 (4 + 4x8).

24-bit Organizationally Unique Identifier.  Information on
OUIs can be found in IEEE 802-2001 [802-2001], Clause 9.

This TC describes a data type which identifies a DSMON
counter aggregation group, which is an arbitrary grouping of
conceptual counters, for monitoring purposes only.  The
range for this data type begins with zero (instead of
one), to allow for a direct mapping between counter
indexing schemes that start at zero (e.g. DSCP values in
packets) and counter aggregation group values.

This TC describes a data type which identifies a DSMON
counter aggregation profile, which is a set of counter
aggregation group assignments for each of the 64 DSCP
values, for a particular statistical collection.

This textual convention enumerates the declaration of
the SatLabs-defined terminal profiles.  The mapping to
the profiles is to be understood as described here.  (0)
refers to the most significant bit.

 dvbs(0) -> DVBS profile (DVB-S support)
 dvbs2ccm(1) -> DVB-S2 CCM profile (CCM support)
 dvbs2acm(2) -> DVB-S2 ACM profile (CCM, VCM and ACM
 support)

This textual convention enumerates the declaration of
the SatLabs-defined options.  A value of 1 indicates
that the respective option is supported.  The mapping
to the options is to be understood as described here.
(0) refers to the most significant bit.

    mpegTrf(0) -> MPEG_TRF
    coarseSync(1) -> COARSE_SYNC
    wideHop(2) -> WIDE_HOPP
    fastHop(3) -> FAST_HOPP
    dynamicMfTdma(4) -> Dynamic_MF_TDMA
    contentionSync(5) -> CONTENTION_SYNC
    qpskLow(6) -> QPSKLOW
    mod16Apsk(7) -> 16APSK
    mod32Apsk(8) -> 32APSK
    normalFec(9) -> NORMALFEC
    multiTs(10) -> MULTITS
    gsTs(11) -> GSTS
    enhQoS(12) -> ENHQOS



    pep(13) -> PEP
    http(14) -> HTTP
    ftp(15) -> FTP
    dns(16) -> DNS
    chIdStrict(17) -> CHID_STRICT
    nlid(18) -> NLID
    snmpMisc(19) -> SNMPMISC

The support of specific options mandates the support of
specific objects and access levels.

This textual convention enumerates the declaration
of the SatLabs-specified compatibility and
configuration features.  A value of 1 indicates that
the respective feature is supported.  The mapping to
the features is to be understood as described here.
(0) refers to the most significant bit.

    rcstPara(0) -> RCST_PARA feature
    installLog(1) -> INSTALL_LOG feature
    enhClassifier(2) -> ENHCLASSIFIER feature
    routeId(3) -> ROUTE_ID feature
    oduList(4) -> ODULIST feature
    extNetwork(5) -> EXTNETWORK feature
    extControl(6) -> EXTCONTROL feature
    extConfig(7) -> EXTCONFIG feature
    extStatus(8) -> EXTSTATUS feature
    mpaf(9) -> MPAF feature

The support of specific features mandates the support of
specific objects and access levels.

Fully-qualified network NAU name. Entries take one of three
forms:
   - Explicit entries do not contain the character '*'.
   - Partial Wildcard entries have the form 'ccc*', where
     'ccc' represents one to sixteen characters in a legal
     SNA NAU Name.
   - A full wildcard  consists of a single character '*'.

Because the characters allowed in an SNA NAU name come from
a restricted character set, these names are not subject to
internationalization.

A unique value, greater than zero, for each PME configuration
profile in the managed EFMCu port.  It is RECOMMENDED that
values are assigned contiguously starting from 1.  The value
for each profile 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
EfmProfileIndex convention.  The latter defines a greater than
zero value used to identify a PME profile in the managed EFMCu
port.  This extension permits the additional value of zero.
The value of zero is object-specific and MUST therefore be
defined as part of the description of any object that uses
this syntax.
Examples of the usage of zero value might include situations
where the current operational profile is unknown.

This textual convention represents a list of up to 6
EfmProfileIndex values, any of which can be chosen for
configuration of a PME in a managed EFMCu port.
The EfmProfileIndex textual convention defines a greater than
zero value used to identify a PME profile.
The value of this object is a concatenation of zero or
more (up to 6) octets, where each octet contains an 8-bit
EfmProfileIndex value.
A zero-length octet string is object-specific and MUST
therefore be defined as part of the description of any object
that uses this syntax.  Examples of the usage of a zero-length
value might include situations where an object using this
textual convention is irrelevant for a specific EFMCu port
type.

This textual convention is an extension of the TruthValue
convention.  The latter defines a boolean value with possible
values of true(1) and false(2).  This extension permits the
additional value of unknown(0), which can be returned as the
result of a GET operation when an exact true or false value
of the object cannot be determined.

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.

A specially formatted SnmpEngineID string for use with the
Entity MIB.

If an instance of an object of SYNTAX SnmpEngineIdOrNone has
a non-zero length, then the object encoding and semantics
are defined by the SnmpEngineID TEXTUAL-CONVENTION (see STD
62, RFC 3411).








If an instance of an object of SYNTAX SnmpEngineIdOrNone
contains a zero-length string, then no appropriate
SnmpEngineID is associated with the logical entity (i.e.,
SNMPv3 is not supported).

Starting with version 4 of the ENTITY-MIB, this TC is
deprecated, and the usage of the IANAPhysicalClass TC from
the IANA-ENTITY-MIB is recommended instead.

An enumerated value that 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; 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 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 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 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 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.

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.

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

 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.

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

The Domain ID of a FC entity in octet form
to support the concatenation(000000h||Domain_ID)
format defined in the FSPF routing protocol.

The type of port mode provided by an FCIP Entity
for an FCIP Link.  An FCIP Entity can be an E-Port
mode for one of its FCIP Link Endpoints or a B-Port
mode for another of its FCIP Link Endpoints.

The FCIP entity identifier as defined in RFC 3821.

The World Wide Name (WWN) associated with a Fibre Channel
(FC) entity.  WWNs were initially defined as 64-bits in
length.  The latest definition (for future use) is 128-bits
long.  The zero-length string value is used in
circumstances in which the WWN is unassigned/unknown.

A Fibre Channel Address ID, a 24-bit value unique within
the address space of a Fabric.  The zero-length string value
is used in circumstances in which the WWN is
unassigned/unknown.

The Domain Id (of an FC switch), or zero if the no Domain
Id has been assigned.

The type of a Fibre Channel port, as indicated by the use
of the appropriate value assigned by IANA.

A set of Fibre Channel classes of service.

The buffer-to-buffer credit of an FC port.

The buffer-to-buffer credit model of an Fx_Port.

The Receive Data Field Size associated with an FC port.

A set of functions that a Fibre Channel Interconnect
Element or Platform might perform.  A value with no bits set
indicates the function(s) are unknown.  The individual bits
have the following meanings:

other - none of the following.

hub - a device that interconnects L_Ports, but does not
operate as an FL_Port.

switch - a fabric element conforming to the Fibre Channel
switch fabric set of standards (e.g., [FC-SW-3]).

bridge - a device that encapsulates Fibre Channel frames
within another protocol (e.g., [FC-BB], FC-BB-2).

gateway - a device that converts an FC-4 to another protocol
(e.g., FCP to iSCSI).

host - a computer system that provides end users with
services such as computation and storage access.

storageSubsys - an integrated collection of storage
controllers, storage devices, and necessary software that
provides storage services to one or more hosts.

storageAccessDev - a device that provides storage management
and access for heterogeneous hosts and heterogeneous devices
(e.g., medium changer).

nas - a device that connects to a network and provides file
access services.

wdmux - a device that modulates/demodulates each of several
data streams (e.g., Fibre Channel protocol data streams)
onto/from a different part of the light spectrum in an
optical fiber.

storageDevice - a disk/tape/etc. device (without the
controller and/or software required for it to be a
'storageSubsys').

Represents time unit value in milliseconds.

Represents time unit value in microseconds.

Represents the Worldwide Name associated with
a Fibre Channel (FC) entity.

Represents Fibre Channel Address ID, a 24-bit
value unique within the address space of a Fabric.

Represents the receive data field size of an
NxPort or FxPort.

Represents the buffer-to-buffer credit of an
NxPort or FxPort.

Represents the version of FC-PH supported by an
NxPort or FxPort.

Represents an enumerated value used to indicate
the Class 1 Stacked Connect Mode supported by
an NxPort or FxPort.

Represents the class of service capability of an
NxPort or FxPort.

Represents the maximum number of modules within
a Fabric Element.

Represents the maximum number of FxPorts within
a module.

Represents the module index within a conceptual table.

Represents the FxPort index within a conceptual table.

Represents the NxPort index within a conceptual table.

Represents the BB_Credit model of an FxPort.

This type represents a 32-bit (4-octet) IEEE
floating-point number in binary interchange format.

This type represents a 64-bit (8-octet) IEEE
floating-point number in binary interchange format.

This type represents a 128-bit (16-octet) IEEE
floating-point number in binary interchange format.

An administratively assigned name for the owner of a
resource, conceptually the same as OwnerString in the RMON
MIB [RMON-MIB].

To facilitate internationalisation, this name 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 the UTF-8 standard [UTF-8].

Indicates the type of a PeerAddress (see below).  The values
used are from the 'Address Family Numbers' section of the
Assigned Numbers RFC [ASG-NBR].  Peer types from other address
families may also be used, provided only that they are
identified by their assigned Address Family numbers.

Specifies the value of a peer address for various network
protocols.  Address format depends on the actual protocol,
as indicated below:

IPv4:        ipv4(1)
    4-octet IpAddress  (defined in the SNMPv2 SMI [RFC2578])

IPv6:        ipv6(2)
    16-octet IpAddress  (defined in the
                            IPv6 Addressing RFC [V6-ADDR])

CLNS:        nsap(3)
    NsapAddress  (defined in the SNMPv2 SMI [RFC2578])

Novell:      ipx(11)
    4-octet Network number,
    6-octet Host number (MAC address)

AppleTalk:   appletalk(12)
    2-octet Network number (sixteen bits),
    1-octet Host number (eight bits)

DECnet:      decnet(13)
    1-octet Area number (in low-order six bits),
    2-octet Host number (in low-order ten bits)

Indicates the type of an adjacent address.  May be a medium
type or (if metering is taking place inside a tunnel) a
PeerType (see above).

The values used for IEEE 802 medium types are from the 'Network
Management Parameters (ifType definitions)' section of the
Assigned Numbers RFC [ASG-NBR].  Other medium types may also
be used, provided only that they are identified by their
assigned ifType numbers.

Specifies the value of an adjacent address.  May be a Medium
Access Control (MAC) address or (if metering is taking place
inside a tunnel) a PeerAddress (see above).

MAC Address format depends on the actual medium, as follows:

Ethernet:     ethernet(7)
    6-octet 802.3 MAC address in 'canonical' order
Token Ring:   tokenring(9)
    6-octet 802.5 MAC address in 'canonical' order

FDDI:         fddi(15)
    FddiMACLongAddress, i.e. a 6-octet MAC address
    in 'canonical' order  (defined in [FDDI-MIB])

Indicates the type of a TransportAddress (see below).  Values
will depend on the actual protocol; for IP they will be those
given in the 'Protocol Numbers' section of the  Assigned Numbers
RFC [ASG-NBR], including icmp(1), tcp(6) and udp(17).

Specifies the value of a transport address for various
network protocols.  Format as follows:

IP:
    2-octet UDP or TCP port number

Other protocols:
    2-octet port number

Specifies the value of an address.  Is a superset of
MediumAddress, PeerAddress and TransportAddress.

Uniquely identifies an attribute within a flow data record.

Uniquely identifies an attribute which may be tested in
a rule.  These include attributes whose values come directly
from (or are computed from) the flow's packets, and the five
'meter' variables used to hold an Attribute Number.

Uniquely identifies the action of a rule, i.e. the Pattern
Matching Engine's opcode number.  Details of the opcodes
are given in the 'Traffic Flow Measurement: Architecture'
document [RTFM-ARC].

The ForCES identifier is a 4-octet quantity.

ForCES protocol version number.
The version numbers used are defined in the
specifications of the respective protocol:
1 - ForCESv1, RFC 5810.

The range of DLCI values.  Note that this varies by
interface configuration; normally, interfaces may use
0..1023, but may be configured to use ranges as large
as 0..2^23.

The possible states for a bundle link, as defined in
Annex A of FRF.16.

The reference point a PVC uses for calculation
of transmitter related statistics.

The valid values for this type of object are as follows:
  - srcLocalRP(1) for the local source
  - ingTxLocalRP(2) for the local ingress queue input
  - tpTxLocalRP(3) for the local traffic policing
  - eqiTxLocalRP(4) for the local egress queue input
  - eqoTxLocalRP(5) for the local egress queue output
  - otherTxLocalRP(6) for any other local transmit point
  - srcRemoteRP(7) for the remote source
  - ingTxLocalRP(8) for the remote ingress queue input
  - tpTxLocalRP(9) for the remote traffic policing
  - eqiTxRemoteRP(10) for the remote egress queue input
  - eqoTxRemoteRP(11) for the remote egress queue output
  - otherTxRemoteRP(12) for any other remote xmit point

The reference point a PVC uses for calculation
of receiver related statistics.

The valid values for this object are as follows:
  - desLocalRP(1) for the local destination
  - ingRxLocalRP(2) for the local ingress queue input
  - tpRxLocalRP(3) for the local traffic policing
  - eqiRxLocalRP(4) for the local egress queue input
  - eqoRxLocalRP(5) for the local egress queue output
  - otherRxLocalRP(6) for any other local receive point
  - desRemoteRP(7) for the remote destination
  - ingRxRemoteRP(8) for the remote ingress input
  - tpRxRemoteRP(9) for the remote traffic policing
  - eqiRxRemoteRP(10) for the remote egress queue input
  - eqoRxRemoteRP(11) for the remote egress queue output
  - otherRxRemoteRP(12) for any other remote receive point

This TEXTUAL-CONVENTION can be used as the syntax of an object
that contains any GMPLS Label.  Objects with this syntax can be
used to represent labels that have label types that are not
defined in any RFCs.  The freeform GMPLS Label may also be used
by systems that do not wish to represent labels that have
label types defined in RFCs using type-specific syntaxes.

Determines the interpretation that should be applied to an
object that encodes a label.  The possible types are:

gmplsMplsLabel(1)           - The label is an MPLS Packet, Cell,
                              or Frame Label and is encoded as
                              described for the TEXTUAL-
                              CONVENTION MplsLabel defined in
                              RFC 3811.

gmplsPortWavelengthLabel(2) - The label is a Port or Wavelength
                              Label as defined in RFC 3471.

gmplsFreeformLabel(3)       - The label is any form of label
                              encoded as an OCTET STRING using
                              the TEXTUAL-CONVENTION
                              GmplsFreeformLabel.

gmplsSonetLabel(4)          - The label is a Synchronous Optical
                              Network (SONET) Label as
                              defined in RFC 4606.

gmplsSdhLabel(5)            - The label is a Synchronous Digital
                              Hierarchy (SDH) Label as defined
                              in RFC 4606.

gmplsWavebandLabel(6)       - The label is a Waveband Label as
                              defined in RFC 3471.

The direction of data flow on an Label Switched Path (LSP)
segment with respect to the head of the LSP.

Where an LSP is signaled using a conventional signaling
protocol, the 'head' of the LSP is the source of the signaling
(also known as the ingress) and the 'tail' is the destination
(also known as the egress).  For unidirectional LSPs, this
usually matches the direction of flow of data.

For manually configured unidirectional LSPs, the direction of
the LSP segment matches the direction of flow of data.  For
manually configured bidirectional LSPs, an arbitrary decision
must be made about which LER is the 'head'.

The Name is a 48-bit quantity.
A 48-bit IEEE 802 MAC address, if
available, may be used.

Defining if partitions are used and how the partition id
is negotiated.

A 8-bit quantity. The format of the Partition ID is not
defined in GSMP. If desired, the Partition ID can be
divided into multiple sub-identifiers within a single



partition. For example: the Partition ID could be
subdivided into a 6-bit partition number and a 2-bit
sub-identifier which would allow a switch to support 64
partitions with 4 available IDs per partition.

The version numbers defined for the GSMP protocol.
The version numbers used are defined in the
specifications of the respective protocol,
1 - GSMPv1.1 [RFC1987]
2 - GSMPv2.0 [RFC2397]
3 - GSMPv3   [RFC3292]
Other numbers may be defined for other versions
of the GSMP protocol.

The label is structured as a TLV, a tuple, consisting of
a Type, a Length, and a Value. The structure is defined
in [RFC 3292]. The label TLV is encoded as a 2 octet type
field, followed by a 2 octet Length field, followed by a
variable length Value field.
Additionally, a label field can be composed of many stacked
labels that together constitute the label.

This data type indicates the validity and sign of the data
in associated object instances which represent the absolute
value of a high capacity numeric quantity.  Such an object
may be represented with one or more object instances. An
object of type HcValueStatus MUST be defined within the same



structure as the object(s) representing the high capacity
absolute value.

If the associated object instance(s) representing the high
capacity absolute value could not be accessed during the
sampling interval, and is therefore invalid, then the
associated HcValueStatus object will contain the value
'valueNotAvailable(1)'.

If the associated object instance(s) representing the high
capacity absolute value are valid and actual value of the
sample is greater than or equal to zero, then the associated
HcValueStatus object will contain the value
'valuePositive(2)'.

If the associated object instance(s) representing the high
capacity absolute value are valid and the actual value of
the sample is less than zero, then the associated
HcValueStatus object will contain the value
'valueNegative(3)'.  The associated absolute value should be
multiplied by -1 to obtain the true sample value.

The CounterBasedGauge64 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 can not be greater than 2^64-1
(18446744073709551615 decimal), and the minimum value can


not be smaller than 0.  The value of a CounterBasedGauge64
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
CounterBasedGauge64 also decreases (increases).

Note that this TC is not strictly supported in SMIv2,
because the 'always increasing' and 'counter wrap' semantics
associated with the Counter64 base type are not preserved.
It is possible that management applications which rely
solely upon the (Counter64) ASN.1 tag to determine object
semantics will mistakenly operate upon objects of this type
as they would for Counter64 objects.

This textual convention represents a limited and short-term
solution, and may be deprecated as a long term solution is
defined and deployed to replace it.

This TC describes an object which counts events with the
following semantics: objects of this type will be set to
zero(0) on creation and will thereafter count appropriate
events, wrapping back to zero(0) when the value 2^64 is
reached.

Provided that an application discovers the new object within
the minimum time to wrap it can use the initial value as a
delta since it last polled the table of which this object is
part.  It is important for a management station to be aware
of this minimum time and the actual time between polls, and
to discard data if the actual time is too long or there is
no defined minimum time.

Typically this TC is used in tables where the INDEX space is
constantly changing and/or the TimeFilter mechanism is in
use.

Note that this textual convention does not retain all the
semantics of the Counter64 base type. Specifically, a
Counter64 has an arbitrary initial value, but objects
defined with this TC are required to start at the value


zero.  This behavior is not likely to have any adverse
effects on management applications which are expecting
Counter64 semantics.

This textual convention represents a limited and short-term
solution, and may be deprecated as a long term solution is
defined and deployed to replace it.

The number of near end intervals for which data was



collected.  The value of an object with an
HCPerfValidIntervals syntax will be 96 unless the
measurement was (re-)started within the last 1440 minutes,
in which case the value will be the number of complete 15
minute intervals for which the agent has at least some data.
In certain cases (e.g., in the case where the agent is a
proxy) it is possible that some intervals are unavailable.
In this case, this interval is the maximum interval number
for which data is available.

The number of near end intervals for which no data is
available.  The value of an object with an
HCPerfInvalidIntervals syntax will typically be zero except
in cases where the data for some intervals are not available
(e.g., in proxy situations).

The number of seconds that have elapsed since the beginning
of the current measurement period.  If, for some reason,
such as an adjustment in the system's time-of-day clock or
the addition of a leap second, the duration of the current
interval exceeds the maximum value, the agent will return
the maximum value.

For 15 minute intervals, the range is limited to (0..899).
For 24 hour intervals, the range is limited to (0..86399).

This convention defines a range of values that may be set
in a fault threshold alarm control.  As the number of
seconds in a 15-minute interval numbers at most 900,
objects of this type may have a range of 0...900, where the
value of 0 disables the alarm.

A gauge associated with a performance measurement in a
current 15 minute measurement interval.  The value of an
object with an HCPerfCurrentCount syntax starts from zero
and is increased when associated events occur, until the
end of the 15 minute interval.  At that time the value of
the gauge is stored in the first 15 minute history
interval, and the gauge is restarted at zero.  In the case
where the agent has no valid data available for the
current interval, the corresponding object instance is not
available and upon a retrieval request a corresponding
error message shall be returned to indicate that this
instance does not exist.

This count represents a non-negative integer, which
may increase or decrease, but shall never exceed 2^64-1
(18446744073709551615 decimal), nor fall below 0.  The
value of an object with HCPerfCurrentCount syntax
assumes its maximum value whenever the underlying count
exceeds 2^64-1.  If the underlying count subsequently
decreases below 2^64-1 (due, e.g., to a retroactive
adjustment as a result of entering or exiting unavailable
time), then the object's value also decreases.

Note that this TC is not strictly supported in SMIv2,
because the 'always increasing' and 'counter wrap'
semantics associated with the Counter64 base type are not
preserved.  It is possible that management applications
which rely solely upon the (Counter64) ASN.1 tag to
determine object semantics will mistakenly operate upon
objects of this type as they would for Counter64 objects.

This textual convention represents a limited and short-
term solution, and may be deprecated as a long term
solution is defined and deployed to replace it.

A gauge associated with a performance measurement in
a previous 15 minute measurement interval.  In the case
where the agent has no valid data available for a
particular interval, the corresponding object instance is
not available and upon a retrieval request a corresponding
error message shall be returned to indicate that this
instance does not exist.

Let X be an object with HCPerfIntervalCount syntax.



Let Y be an object with HCPerfCurrentCount syntax.
Let Z be an object with HCPerfTotalCount syntax.
Then, in a system supporting a history of n intervals with
X(1) and X(n) the most and least recent intervals
respectively, the following applies at the end of a 15
minute interval:

   - discard the value of X(n)
   - the value of X(i) becomes that of X(i-1)
     for n >= i > 1
   - the value of X(1) becomes that of Y.
   - the value of Z, if supported, is adjusted.

This count represents a non-negative integer, which
may increase or decrease, but shall never exceed 2^64-1
(18446744073709551615 decimal), nor fall below 0.  The
value of an object with HCPerfIntervalCount syntax
assumes its maximum value whenever the underlying count
exceeds 2^64-1.  If the underlying count subsequently
decreases below 2^64-1 (due, e.g., to a retroactive
adjustment as a result of entering or exiting unavailable
time), then the value of the object also decreases.

Note that this TC is not strictly supported in SMIv2,
because the 'always increasing' and 'counter wrap'
semantics associated with the Counter64 base type are not
preserved.  It is possible that management applications
which rely solely upon the (Counter64) ASN.1 tag to
determine object semantics will mistakenly operate upon
objects of this type as they would for Counter64 objects.

This textual convention represents a limited and short-
term solution, and may be deprecated as a long term
solution is defined and deployed to replace it.

A gauge representing the aggregate of previous valid 15
minute measurement intervals.  Intervals for which no
valid data was available are not counted.

This count represents a non-negative integer, which
may increase or decrease, but shall never exceed 2^64-1
(18446744073709551615 decimal), nor fall below 0.  The
value of an object with HCPerfTotalCount syntax
assumes its maximum value whenever the underlying count



exceeds 2^64-1.  If the underlying count subsequently
decreases below 2^64-1 (due, e.g., to a retroactive
adjustment as a result of entering or exiting unavailable
time), then the object's value also decreases.

Note that this TC is not strictly supported in SMIv2,
because the 'always increasing' and 'counter wrap'
semantics associated with the Counter64 base type are not
preserved.  It is possible that management applications
which rely solely upon the (Counter64) ASN.1 tag to
determine object semantics will mistakenly operate upon
objects of this type as they would for Counter64 objects.

This textual convention represents a limited and short-
term solution, and may be deprecated as a long term
solution is defined and deployed to replace it.

A gauge associated with interface performance measurements in
a current 1-day (24 hour) measurement interval.

The value of this gauge starts at zero at the beginning of an
interval and is increased when associated events occur, until
the end of the 1-day interval.  At that time, the value of the
gauge is stored in the previous 1-day history interval, as
defined in a companion object of type
Hdsl2Shdsl1DayIntevalCount, and the current interval gauge
is restarted at zero.

In the case where the agent has no valid data available for
this interval, the corresponding object instance is not
available, and upon a retrieval request, a corresponding error
message shall be returned to indicate that this instance does
not exist.  Please note that zero is a valid value.

A counter associated with interface performance measurements
during the most previous 1-day (24 hour) measurement interval.
The value of this gauge is equal to the value of the current
day gauge, as defined in a companion object of type
Hdsl2ShdslPerfCurrDayCount, at the end of its most recent
interval.

In the case where the agent has no valid data available for
this interval, the corresponding object instance is not
available, and upon a retrieval request, a corresponding error
message shall be returned to indicate that this instance does
not exist.

The number of seconds that have elapsed since the beginning of
the current measurement period.  If, for some reason, such as
an adjustment in the system's time-of-day clock or the addition
of a leap second, the current interval exceeds the maximum
value, the agent will return the maximum value.

For 15-minute intervals, the range is limited to (0..899).
For 24-hour intervals, the range is limited to (0..86399).

This convention defines a range of values that may be set in
a fault threshold alarm control.  As the number of seconds in
a 15-minute interval numbers at most 900, objects of this type
may have a range of 0...900, where the value of 0 disables the
alarm.

This is the unique identification for all units in an
HDSL2/SHDSL span.  It is based on the EOC unit addressing
scheme with reference to the xtuC.

This is the referenced side of an HDSL2/SHDSL unit - Network
or Customer side.  The side facing the Network is the Network
side, while the side facing the Customer is the Customer side.

This is the referenced pair of wires in an HDSL2/SHDSL segment.
HDSL2 only supports a single pair (wirePair1 or two wire),
SHDSL lines support an optional second pair (wirePair2 or four
wire), and G.shdsl.bis support an optional third pair
(wirePair3 or six wire) and an optional fourth pair
(wirePair4 or eight wire).

Contains the regional setting of the HDSL2/SHDSL span,
represented as a bit-map of possible settings.  The various
bit positions are as follows:



Bit   Meaning      Description
1     region 1     Indicates ITU-T G.991.2 Annex A.
2     region 2     Indicates ITU-T G.991.2 Annex B.

The various STU-C symbol clock references for the
HDSL2/SHDSL span, represented as an enumeration.

Storage size, expressed in units of 1024 bytes.

This textual convention is intended to identify the
manufacturer, model, and version of a specific
hardware or software product.  It is suggested that
these OBJECT IDENTIFIERs are allocated such that all
products from a particular manufacturer are registered
under a subtree distinct to that manufacturer.  In
addition, all versions of a product should be
registered under a subtree distinct to that product.
With this strategy, a management station may uniquely
determine the manufacturer and/or model of a product
whose productID is unknown to the management station.
Objects of this type may be useful for inventory
purposes or for automatically detecting
incompatibilities or version mismatches between
various hardware and software components on a system.

For example, the product ID for the ACME 4860 66MHz
clock doubled processor might be:
enterprises.acme.acmeProcessors.a4860DX2.MHz66

A software product might be registered as:
enterprises.acme.acmeOperatingSystems.acmeDOS.six(6).one(1)

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.

APPN traffic type.  The first four values correspond
to APPN transmission priorities (network, high, medium and
low), while the fifth is used for both LLC commands (XID,
TEST, DISC, and DM) and function-routed NLPs (XID_DONE_RQ
and XID_DONE_RSP).

A DisplayString representing the setting of the three TOS
Precedence bits in the IP Type of Service field for this APPN
traffic type.  The HPR over IP architecture specifies the
following default mapping:

     APPN traffic type           IP TOS Precedence bits
     ------------------          ----------------------
      Network                     110
      High                        100
      Medium                      010
      Low                         001
      LLC commands, etc.          110

A bit string identifying the set of functions provided by a
network connection endpoint (NCE).  The following values are
defined:

      bit 0:  control point
      bit 1:  logical unit
      bit 2:  boundary function
      bit 3:  route setup

An object providing statistics for an RTP connection.  A
Management Station can detect discontinuities in this counter
by monitoring the correspondingly indexed
hprRtpCounterDisconTime object.

ITU-T probable cause values.  Duplicate values defined in
X.733 are appended with X733 to ensure syntactic uniqueness.
Probable cause value 0 is reserved for special purposes.

The Internet Assigned Number Authority (IANA) is responsible
for the assignment of the enumerations in this TC.
IANAItuProbableCause value of 0 is reserved for special
purposes and MUST NOT be assigned.

Values of IANAItuProbableCause in the range 1 to 1023 are
reserved for causes that correspond to ITU-T probable cause.

All other requests for new causes will be handled on a
first-come, first served basis and will be assigned
enumeration values starting with 1025.

Request should  come in the form of well-formed


SMI [RFC2578] for enumeration names that are unique and
sufficiently descriptive.

While some effort will be taken to ensure that new probable
causes do not conceptually duplicate existing probable
causes it is acknowledged that the existence of conceptual
duplicates in the starting probable cause list is an known
industry reality.

To aid IANA in the administration of probable cause names
and values, the OPS Area Director will appoint one or more
experts to help review requests.

See http://www.iana.org

The ITU event Type values.

The Internet Assigned Number Authority (IANA) is
responsible for the assignment of the enumerations
in this TC.

Request should  come in the form of well-formed
SMI [RFC2578] for enumeration names that are unique
and sufficiently descriptive.

See http://www.iana.org

The maximum propagation delay, in seconds,
for an encapsulated FC frame to traverse the
IP network.  A value of 0 implies fibre
channel frame lifetime limits will not be
enforced.

The value for the Liveness Test Interval
(LTI) being used in an iFCP connection, in
seconds.  A value of 0 implies no Liveness
Test Interval will be used.

The value for an iFCP session state.

The values for iFCP Address Translation
Mode.

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

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.

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

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

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.

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.

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

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.

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

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.

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 size of a message in bytes. This  is  used
to  specify  the  minimum and maximum size of a
message along an integrated services route.

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.

The class of service in use by a flow.

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

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.

An RFC 1766-style language tag, with all alphabetic
characters converted to lowercase.  This restriction is
intended to make the lexical ordering imposed by SNMP useful


when applied to language tags.  Note that it is
theoretically possible for a valid language tag to exceed
the allowed length of this syntax, and thus be impossible to
represent with this syntax.  Sampling of language tags in
current use on the Internet suggests that this limit does
not pose a serious problem in practice.

The encapsulation type used on a VC.

An integer large enough to contain the value of a VPI.

An integer large enough to contain the value of a VCI.

The ATM address used by the network entity.
The semantics are implied by the length.
The address types are:

- no address (0 octets)
- E.164 (8 octets)
- NSAP (20 octets)

In addition, when subaddresses are used IpoaAtmAddr
may represent the concatenation of address and
subaddress.  The associated address types are:

- E.164, E.164 (16 octets)
- E.164, NSAP (28 octets)
- NSAP, NSAP (40 octets)
Address lengths other than defined in this definition
imply address types defined elsewhere.
Note: The E.164 address is encoded in BCD format.

The use of call control.  The use is as follows:
pvc(1)
   Virtual link of a PVC.  Should not be
   used in a PVC/SVC (i.e., SPVC)
   crossconnect.
svcIncoming(2)
   Virtual link established after a
   received signaling request to setup
   an SVC.
svcOutgoing(3)
   Virtual link established after a
   transmitted or forwarded signaling
   request to setup an SVC.
spvcInitiator(4)
   Virtual link at the PVC side of an
   SVC/PVC crossconnect, where the
   switch is the initiator of the SPVC
   setup.
spvcTarget(5)
   Virtual link at the PVC side of an
   SVC/PVC crossconnect, where the
   switch is the target of the SPVC
   setup.

An spvcInitiator is always cross-connected to
an svcOutgoing, and an spvcTarget is always
cross-connected to an svcIncoming.

IP Storage requires the use of address information
that uses not only the InetAddress type defined in the
INET-ADDRESS-MIB, but also Fibre Channel type defined
in the Fibre Channel Management MIB.  Although these
address types are recognized in the IANA Address Family
Numbers MIB, the addressing mechanisms have not been
merged into a well-known, common type.  This data type,
the IpsAuthAddress, performs the merging for this MIB
module.

The formats of objects of this type are determined by
a corresponding object with syntax AddressFamilyNumbers,
and thus every object defined using this TC must
identify the object with syntax AddressFamilyNumbers
that specifies its type.

The syntax and semantics of this object depend on the
identified AddressFamilyNumbers object as follows:

AddressFamilyNumbers   this object
====================   ===========
ipV4(1)                restricted to the same syntax and
                       semantics as the InetAddressIPv4 TC.

ipV6(2)                restricted to the same syntax and
                       semantics as the InetAddressIPv6 TC.

fibreChannelWWPN (22)
& fibreChannelWWNN(23) restricted to the same syntax and
                       semantics as the FcNameIdOrZero TC.

Types other than the above should not be used unless



the corresponding format of the IpsAuthAddress object is
further specified (e.g., in a future revision of this TC).

The SpdBooleanOperator operator is used to specify
whether sub-components in a decision-making process are



ANDed or ORed together to decide if the resulting
expression is true or false.

The SpdAdminStatus is used to specify the administrative
status of an object.  Objects that are disabled MUST NOT
be used by the packet processing engine.

SpdIPPacketLogging specifies whether an audit message
SHOULD be logged if a packet is passed through a Security
Association (SA) and if some of that packet is included in
the log event.  A value of '-1' indicates no logging.  A
value of '0' or greater indicates that logging SHOULD be
done and indicates the number of bytes starting at the
beginning of the packet to place in the log.  Values greater
than the size of the packet being processed indicate that
the entire packet SHOULD be sent.

Examples:
'-1' no logging
'0'  log but do not include any of the packet in the log
'20' log and include the first 20 bytes of the packet
     in the log.

This property identifies an overall range of calendar dates
and time.  In a boolean context, a value within this time
range, inclusive, is considered true.

This information is encoded as an octet string using
the UTF-8 transformation format described in STD 63,
RFC 3629.

It uses the format suggested in RFC 3060.  An octet string



represents a start date and time and an end date and time.
For example:

yyyymmddThhmmss/yyyymmddThhmmss

Where: yyyy = year     mm = month     dd = day
         hh = hour     mm = minute    ss = second

The first 'yyyymmddThhmmss' sub-string indicates the start
date and time.  The second 'yyyymmddThhmmss' sub-string
indicates the end date and time.  The character 'T' within
these sub-strings indicates the beginning of the time
portion of each sub-string.  The solidus character '/'
separates the start from the end date and time.  The end
date and time MUST be subsequent to the start date and
time.

There are also two allowed substitutes for a
'yyyymmddThhmmss' sub-string: one for the start date and
time, and one for the end date and time.

If the start date and time are replaced with the string
'THISANDPRIOR', this sub-string would indicate the current
date and time and the previous dates and time.

If the end date and time are replaced with the string
'THISANDFUTURE', this sub-string would indicate the current
date and time and the subsequent dates and time.

Any of the following SHOULD be considered a
'wrongValue' error:
- Setting a value with the end date and time earlier than
  or equal to the start date and time.
- Setting the start date and time to 'THISANDFUTURE'.
- Setting the end date and time to 'THISANDPRIOR'.

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

The flow identifier or Flow Label in an IPv6
packet header that may be used to discriminate
traffic flows.  The value of -1 is used to
indicate a wildcard, i.e. any value.

This data type is used to model IPv6 addresses.
This is a binary string of 16 octets in network
byte-order.

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

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.

A unique value, greater than zero for each
internetwork-layer interface in the managed
system. It is recommended that values are assigned
contiguously starting from 1. The value for each
internetwork-layer interface 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
Ipv6IfIndex convention.  The latter defines
a greater than zero value used to identify an IPv6
interface 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 define the transport
protocols that will carry iSCSI PDUs.

This data type represents the methods possible
for digest negotiation.
none     - a placeholder for a secondary digest method
           that means only the primary method can be
           used.
other    - a digest method other than those defined below.
noDigest - does not support digests (will operate without
           a digest (Note: implementations must support
           digests to be compliant with the RFC3720).
CRC32c   - require a CRC32C digest.

This data type is used for objects whose value is an
iSCSI name with the properties described in RFC 3720
section 3.2.6.1, and encoded as specified in RFC 3720
section 3.2.6.2.  A zero-length string indicates the
absence of an iSCSI name.

This data type is used as the syntax of the
isdnSignalingProtocol object in the
definition of ISDN-MIB's isdnSignalingTable.

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

OSI Network Service Address, e.g., NSAP, SNPA, or Network
Entity Title

The ID for an Intermediate System.  This should
be unique within a network, and is included
in all PDUs originated by an Intermediate System.
The protocol does not place any meanings upon
the bits, other than using ordering to break
ties in electing a Designated IS on a LAN.

The 8-byte Link State PDU (LSP) ID,
consisting of the 6-byte SystemID of the
originating IS; a one-byte PseudoNode ID,
which is 0 unless the LSP represents the
topology of a LAN; and a one-byte LSP
fragment number that is issued in sequence,
starting with 0.  Non-zero PseudoNode IDs
need to be unique to the IS but need not
match the IfIndex.

Type used in enabling and disabling a row.

Integer sub-range for maximum LSP size.

States of the IS-IS protocol.

Types of network protocol supported by Integrated IS-IS.
The values for ISO8473 and IP are those registered for
these protocols in ISO TR9577.

Integer sub-range for default metric for single hop.
ISO 10589 provides for 4 types of metric.  Only the
'default' metric is used in practice.

Wide metric for IS Neighbors.  ISO 10589 provides a
6-bit metric.  Traffic Engineering extensions provide
24-bit metrics.

Full metric for IP Routes.  Traffic Engineering extensions
provide 32-bit metrics.

Is this an Internal or External Metric?

Do we use RFC 1195 style metrics or wide metrics?

Identifies a level.

Identifies one or more levels.

A block to contain the header from a PDU.

ID for a circuit.

Integer sub-range for IS-IS priority.

An Unsigned32 further restricted to 16 bits.  Note that
the ASN.1 BER encoding may still require 24 bits for
some values.

An Unsigned32 further restricted to 8 bits.  Note that
the ASN.1 BER encoding may still require 16 bits for
some values.

The unique Discovery Domain Set Identifier associated with a
Discovery Domain Set (DDS).

The status of a Discovery Domain Set (DDS) registered in the
iSNS.  The initially assigned values are below:
             Bit           Status
          ---------       ---------
             31            DDS Enabled
          All others       RESERVED

Setting a bit to 1 indicates the feature is enabled.
Otherwise, it is disabled.  The future assignment of any of
the reserved values will be documented in a revision of
RFC 4171.

The unique Discovery Domain Identifier (DD_ID) associated



with each Discovery Domain (DD).  This is used to
uniquely index and reference a DD.

This type defines the features that each Discovery Domain
(DD) has.
             Bit           Status
          ---------       ---------
             31            Boot List
          All others       RESERVED

Boot List: this feature indicates that the targets
in this DD provide boot capabilities for the member
initiators.

Setting a bit to 1 indicates the feature is enabled.
Otherwise, it is disabled.  The future assignment of any of
the reserved values will be documented in a revision of
RFC 4171.

The methods that can be used to modify the Discovery
Domain and Discovery Domain Sets in an iSNS Server
instance.
       Bit             Flag Description
    ---------   ------------------------------------
        0       Control Nodes are allowed



        1       Target iSCSI Nodes are allowed
        2       Initiator iSCSI Nodes are allowed
        3       Target iFCP Ports are allowed
        4       Initiator iFCP Ports are allowed

Setting a bit to 1 indicates the feature is
enabled.  Otherwise, it is disabled.

The identifier for the unique integer Entity Index
associated with an iSNS registered Entity object, and the
value zero.  The value zero is object-specific and MUST
therefore 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 Entity is unknown,
or not yet registered in the iSNS server.  If a value of
zero is not valid for an object, then that MUST be
indicated.

The identifier for the unique integer Portal Group Index
associated with an iSNS registered Portal Group object.

The identifier for the unique integer Portal Index
associated with an iSNS registered Portal object.  The
index is created by the iSNS Server for mapping between



registered objects.  The Portal Index used for a specific
portal IP-address and port number pair is only persistent
across reboots for portals that have been explicitly added
to a Discovery Domain (DD).  If a portal is not explicitly
registered in any DD, then the index used for a portal can
change after a server reinitialization.

The UDP or TCP port type being used by a Portal for an
Entity.

The Portal Group Tag (PGT) represents an association
between a Portal and iSCSI Node using the value range
0 to 65535.  A PGT with no association is a NULL
value.  The value of -1 indicates a NULL value.

Indicates security attribute settings for a Portal that is
registered in the iSNS server.  The bitmapVALID field must
be set in order for the contents to be considered valid
information.  The definitions of the bit fields are based
on RFC 4171.  The initial representation of each bit setting
(0 or 1) is indicated below.
      Bit             Flag Description
    ---------   ------------------------------------
       25       1 = Tunnel Mode Preferred; 0 = No Preference
       26       1 = Transport Mode Preferred; 0 = No
                Preference
       27       1 = PFS Enabled; 0 = PFS Disabled
       28       1 = Aggressive Mode Enabled; 0 = Disabled
       29       1 = Main Mode Enabled; 0 = MM Disabled
       30       1 = IKE/IPsec Enabled; 0 = IKE/IPsec
                Disabled
       31       1 = Bitmap VALID; 0 = INVALID



    All others  RESERVED

The future assignment of any of the reserved values will be
documented in a revision of RFC 4171.

The identifier for the unique integer Node Index associated
with a storage node.  This index provides a 1-to-1 mapping
to an iSCSI node name.  The iSCSI node name maximum length
is too long to be used for an index directly.  The iSCSI
node index used for a specific iSCSI node name is identical
in all DDs, and is persistent across server
reinitializations when the iSCSI node is a member of a
Discovery Domain (DD) or is registered as a Control Node.
Furthermore, index values for recently deregistered objects
SHOULD NOT be reused in the short term.

The iSCSI Node Type defines the functions of the registered
object.  The definitions of each setting are defined in
RFC 4171.
             Bit          Node Type



          ---------       ---------
             29            Control
             30            Initiator
             31            Target
          All others       RESERVED

Setting a bit to 1 indicates the node has the corresponding
characteristics.  The future assignment of any of the
reserved values will be documented in a revision of
RFC 4171.

This defines the Fibre Channel Class of Service types
that are supported by the registered port.  The
definitions are as defined in RFC 4171.
      Bit              FC COS Type
    ---------          ----------------
       28             Fibre Channel Class 3 Supported
       29             Fibre Channel Class 2 Supported
    All others        RESERVED

Setting a bit to 1 indicates the class of service is
supported.  The future assignment of any of the
reserved values will be documented in a revision of
RFC 4171.

The iSCSI Node State Change Notification (SCN) values
for a node as defined in RFC 4171.
         Bit                Description
      ------------       ----------------
       24                Initiator and self information only
       25                Target and self information only
       26                Management registration/SCN
       27                Object removed
       28                Object added
       29                Object updated
       30                DD or DDS member removed (Mgmt
                         Reg/SCN only)
       31 (Lsb)          DD or DDS member added (Mgmt
                         Reg/SCN only)
       All others        Reserved

Setting a bit to 1 indicates that type of SCN is enabled.
The future assignment of any of the reserved values will be
documented in a revision of RFC 4171.

The iFCP State Change Notification (SCN) values for an iFCP
object as defined in RFC 4171.
         Bit                Description
      ------------       ----------------
       24                Initiator and self information only
       25                Target and self information only
       26                Management registration/SCN
       27                Object removed
       28                Object added
       29                Object updated
       30                DD or DDS member removed (Mgmt
                         Reg/SCN only)
       31 (Lsb)          DD or DDS member added (Mgmt
                         Reg/SCN only)
       All others        Reserved

Setting a bit to 1 indicates that type of SCN is enabled.
The future assignment of any of the reserved values will be
documented in a revision of RFC 4171.

The FC Port Role defines the functions of the registered
object.  The definitions of each setting are defined in
RFC 4171.
             Bit          Port Role
          ---------       ---------
             29            Control
             30            FCP Initiator
             31            FCP Target
         All others        RESERVED

Setting a bit to 1 indicates the port has the corresponding
characteristics.  The future assignment of any of the
reserved values will be documented in a revision of
RFC 4171.

The types of iSNS Server discovery methods that are enabled
on an iSNS Server.  The options are DHCP, Service Location
Protocol (SLP), multicast group iSNS heartbeat, broadcast
group iSNS heartbeat, configured server list, and other.
The iSNS Server may support additional discovery methods
not indicated.

ITU perceived severity values

ITU trend indication values for alarms.

To facilitate internationalization, this TC represents
information taken from the ISO/IEC IS 10646-1 character set,
encoded as an octet string using the UTF-8 character encoding
scheme.

See section 3.6.1, entitled: 'Text generated by the server or
device'.

To facilitate internationalization, this TC represents
information using any coded character set registered by IANA as
specified in section 3.7.  While it is recommended that the
coded character set be UTF-8 [UTF-8], the actual coded
character set SHALL be indicated by the value of the
jobCodedCharSet(8) attribute for the job.

See section 3.6.2, entitled: 'Text supplied by the job
submitter'.

An IETF RFC 1766-compliant 'language tag', with zero or more
sub-tags that identify a natural language.  While RFC 1766
specifies that the US-ASCII values are case-insensitive, this
MIB specification requires that all characters SHALL be lower
case in order to simplify comparing by management applications.

See section 3.6.1, entitled: 'Text generated by the server or
device' and section 3.6.2, entitled: 'Text supplied by the job
submitter'.

The simple time at which an event took place.  The units are
in seconds since the system was booted.

NOTE - JmTimeStampTC is defined in units of seconds, rather
than 100ths of seconds, so as to be simpler for agents to
implement (even if they have to implement the 100ths of a
second to comply with implementing sysUpTime in MIB-II[mib-
II].)

NOTE - JmTimeStampTC is defined as an Integer32 so that it can
be used as a value of an attribute, i.e., as a value of the
jmAttributeValueAsInteger object.  The TimeStamp textual-
convention defined in SNMPv2-TC [SMIv2-TC] is defined as an
APPLICATION 3 IMPLICIT INTEGER tag, not an Integer32 which is
defined in SNMPv2-SMI [SMIv2-TC] as UNIVERSAL 2 IMPLICIT
INTEGER, so cannot be used in this MIB as one of the values of
jmAttributeValueAsInteger.

The source platform type that can submit jobs to servers or
devices in any of the 3 configurations.

This is a type 2 enumeration.  See Section 3.7.1.2.  See also
IANA operating-system-names registry.

The type of finishing operation.

These values are the same as the enum values of the IPP
'finishings' attribute.  See Section 3.7.1.2.

other(1),
    Some other finishing operation besides one of the specified
    or registered values.

unknown(2),
    The finishing is unknown.

none(3),
    Perform no finishing.

staple(4),
    Bind the document(s) with one or more staples. The exact
    number and placement of the staples is site-defined.

punch(5),
    Holes are required in the finished document. The exact
    number and placement of the holes is site-defined.  The
    punch specification MAY be satisfied (in a site- and
    implementation-specific manner) either by
    drilling/punching, or by substituting pre-drilled media.

cover(6),
    Select a non-printed (or pre-printed) cover for the
    document. This does not supplant the specification of a
    printed cover (on cover stock medium) by the document
    itself.

bind(7)
    Binding is to be applied to the document; the type and
    placement of the binding is product-specific.

This is a type 2 enumeration.  See Section 3.7.1.2.

Print quality settings.

These values are the same as the enum values of the IPP 'print-
quality' attribute.  See Section 3.7.1.2.

This is a type 2 enumeration.  See Section 3.7.1.2.

Printer resolutions.

Nine octets consisting of two 4-octet SIGNED-INTEGERs followed
by a SIGNED-BYTE.  The values are the same as those specified
in the Printer MIB [printmib]. The first SIGNED-INTEGER
contains the value of prtMarkerAddressabilityXFeedDir.  The
second SIGNED-INTEGER contains the value of
prtMarkerAddressabilityFeedDir.  The SIGNED-BYTE contains the
value of prtMarkerAddressabilityUnit.

Note: the latter value is either 3 (tenThousandsOfInches) or 4
(micrometers) and the addressability is in 10,000 units of
measure. Thus the SIGNED-INTEGERs represent integral values in
either dots-per-inch or dots-per-centimeter.

The syntax is the same as the IPP 'printer-resolution'
attribute.  See Section 3.7.1.2.

Toner economy settings.

This is a type 2 enumeration.  See Section 3.7.1.2.

Boolean true or false value.

This is a type 2 enumeration.  See Section 3.7.1.2.

Identifies the type of medium.

other(1),
    The type is neither one of the values listed in this
    specification nor a registered value.

unknown(2),
    The type is not known.

stationery(3),
    Separately cut sheets of an opaque material.

transparency(4),
    Separately cut sheets of a transparent material.

envelope(5),
    Envelopes that can be used for conventional mailing
    purposes.

envelopePlain(6),
    Envelopes that are not preprinted and have no windows.

envelopeWindow(7),
    Envelopes that have windows for addressing purposes.

continuousLong(8),
    Continuously connected sheets of an opaque material
    connected along the long edge.

continuousShort(9),
    Continuously connected sheets of an opaque material
    connected along the short edge.

tabStock(10),
    Media with tabs.

multiPartForm(11),
    Form medium composed of multiple layers not pre-attached to
    one another;  each sheet MAY be drawn separately from an
    input source.

labels(12),
    Label-stock.

multiLayer(13)
    Form medium composed of multiple layers which are pre-
    attached to one another, e.g. for use with impact printers.
This is a type 2 enumeration.  See Section 3.7.1.2.  These enum
values correspond to the keyword name strings of the
prtInputMediaType object in the Printer MIB [print-mib].  There
is no printer description attribute in IPP/1.0 that represents
these values.

This value is the type of job collation.  Implementations that
don't support multiple documents or don't support multiple
copies SHALL NOT support the uncollatedDocuments(5) value.

This is a type 2 enumeration.  See Section 3.7.1.2. See also
Section 3.4, entitled 'Monitoring Job Progress'.

Identifies the format type of a job submission ID.

Each job submission ID is a fixed-length, 48-octet printable
US-ASCII [US-ASCII] coded character string containing no
control characters, consisting of the fields defined in section
3.5.1.

This is like a type 2 enumeration.  See section 3.7.3.

The current state of the job (pending, processing, completed,
etc.).  The following figure shows the normal job state
transitions:

                                            +----> canceled(7)
                                           /
+---> pending(3) -------> processing(5) ------+------> completed(9)
|         ^                      ^             \
--->+         |                      |              +----> aborted(8)
|         v                      v             /
+---> pendingHeld(4)  processingStopped(6) ---+


        Figure 4 - Normal Job State Transitions

Normally a job progresses from left to right.  Other state
transitions are unlikely, but are not forbidden.  Not shown are
the transitions to the canceled state from the pending,
pendingHeld, and processingStopped states.

Jobs in the pending, processing, and processingStopped states
are called 'active', while jobs in the pendingHeld, canceled,
aborted, and completed states are called 'inactive'.  Jobs
reach one of the three terminal states: completed, canceled, or
aborted, after the jobs have completed all activity, and all
MIB objects and attributes have reached their final values for
the job.
These values are the same as the enum values of the IPP 'job-
state' job attribute.  See Section 3.7.1.2.

unknown(2),
    The job state is not known, or its state is indeterminate.

pending(3),
    The job is a candidate to start processing, but is not yet
    processing.

pendingHeld(4),
    The job is not a candidate for processing for any number of
    reasons but will return to the pending state as soon as the
    reasons are no longer present.  The job's
    jmJobStateReasons1 object and/or jobStateReasonsN (N=2..4)
    attributes SHALL indicate why the job is no longer a
    candidate for processing.  The reasons are represented as
    bits in the jmJobStateReasons1 object and/or
    jobStateReasonsN (N=2..4) attributes.  See the
    JmJobStateReasonsNTC (N=1..4) textual convention for the
    specification of each reason.

processing(5),
    One or more of:

    1.  the job is using, or is attempting to use, one or
    more purely software processes that are analyzing,
    creating, or interpreting a PDL, etc.,

    2.  the job is using, or is attempting to use, one or
    more hardware devices that are interpreting a PDL,
    making mark on a medium, and/or performing finishing,
    such as stapling, etc.,  OR

    3. (configuration 2) the server has made the job ready
    for printing, but the output device is not yet printing
    it, either because the job hasn't reached the output
    device or because the job is queued in the output
    device or some other spooler, awaiting the output
    device to print it.

    When the job is in the processing state, the entire job
    state includes the detailed status represented in the
    device MIB indicated by the hrDeviceIndex value of the
    job's physicalDevice attribute, if the agent implements
    such a device MIB.

    Implementations MAY, though they NEED NOT, include
    additional values in the job's jmJobStateReasons1 object
    to indicate the progress of the job, such as adding the
    jobPrinting value to indicate when the device is actually
    making marks on a medium and/or the processingToStopPoint
    value to indicate that the server or device is in the
    process of canceling or aborting the job.

processingStopped(6),
    The job has stopped while processing for any number of
    reasons and will return to the processing state as soon
    as the reasons are no longer present.

    The job's jmJobStateReasons1 object and/or the job's
    jobStateReasonsN (N=2..4) attributes MAY indicate why the
    job has stopped processing.  For example, if the output
    device is stopped, the deviceStopped value MAY be
    included in the job's jmJobStateReasons1 object.

    NOTE - When an output device is stopped, the device
    usually indicates its condition in human readable form
    at the device.  The management application can obtain
     more complete device status remotely by querying the
    appropriate device MIB using the job's deviceIndex
    attribute(s), if the agent implements such a device MIB

canceled(7),
    A client has canceled the job and the server or device
    has completed canceling the job AND all MIB objects and
    attributes have reached their final values for the job.
    While the server or device is canceling the job, the
    job's jmJobStateReasons1 object SHOULD contain the
    processingToStopPoint value and one of the
    canceledByUser, canceledByOperator, or canceledAtDevice
    values.  The canceledByUser, canceledByOperator, or
    canceledAtDevice values remain while the job is in the
    canceled state.

aborted(8),
    The job has been aborted by the system, usually while the
    job was in the processing or processingStopped state and
    the server or device has completed aborting the job AND
    all MIB objects and attributes have reached their final
    values for the job.  While the server or device is
    aborting the job, the job's jmJobStateReasons1 object MAY
    contain the processingToStopPoint and abortedBySystem
    values.  If implemented, the abortedBySystem value SHALL
    remain while the job is in the aborted state.
completed(9)
    The job has completed successfully or with warnings or
    errors after processing and all of the media have been
    successfully stacked in the appropriate output bin(s) AND
    all MIB objects and attributes have reached their final
    values for the job.  The job's jmJobStateReasons1 object
    SHOULD contain one of: completedSuccessfully,
    completedWithWarnings, or completedWithErrors values.

This is a type 2 enumeration.  See Section 3.7.1.2.

The type of the attribute which identifies the attribute.

NOTE - The enum assignments are grouped logically with values
assigned in groups of 20, so that additional values may be
registered in the future and assigned a value that is part of
their logical grouping.

Values in the range 2**30 to 2**31-1 are reserved for private
or experimental usage.  This range corresponds to the same
range reserved in IPP.  Implementers are warned that use of
such values may conflict with other implementations.
Implementers are encouraged to request registration of enum
values following the procedures in Section 3.7.1.

See Section 3.2 entitled 'The Attribute Mechanism' for a
description of this textual-convention and its use in the
jmAttributeTable.  See Section 3.3.8 for the specification of
each attribute.  The comment(s) after each enum assignment
specifies the data type(s) of the attribute.

This is a type 2 enumeration.  See Section 3.7.1.2.

Specifies the type(s) of service to which the job has been
submitted (print, fax, scan, etc.).  The service type is
represented as an enum that is bit encoded with each job
service type so that more general and arbitrary services can be
created, such as services with more than one destination type,
or ones with only a source or only a destination.  For example,
a job service might scan, faxOut, and print a single job.  In
this case, three bits would be set in the jobServiceTypes
attribute, corresponding to the hexadecimal values: 0x8 + 0x20
+ 0x4, respectively, yielding: 0x2C.

Whether this attribute is set from a job attribute supplied by
the job submission client or is set by the recipient job
submission server or device depends on the job submission
protocol.  With either implementation, the agent SHALL return a
non-zero value for this attribute indicating the type of the
job.

One of the purposes of this attribute is to permit a requester
to filter out jobs that are not of interest.  For example, a
printer operator MAY only be interested in jobs that include
printing.  That is why the attribute is in the job
identification category.

The following service component types are defined (in
hexadecimal) and are assigned a separate bit value for use with
the jobServiceTypes attribute:

other                             0x1
    The job contains some instructions that are not one of the
    identified types.

unknown                           0x2
    The job contains some instructions whose type is unknown to
    the agent.

print                             0x4
    The job contains some instructions that specify printing

scan                              0x8
    The job contains some instructions that specify scanning

faxIn                             0x10
    The job contains some instructions that specify receive fax

faxOut                            0x20
    The job contains some instructions that specify sending fax

getFile                           0x40
    The job contains some instructions that specify accessing
    files or documents

putFile                           0x80
    The job contains some instructions that specify storing
    files or documents

mailList                          0x100
    The job contains some instructions that specify
    distribution of documents using an electronic mail system.

These bit definitions are the equivalent of a type 2 enum
except that combinations of them MAY be used together.  See
section 3.7.1.2.

The JmJobStateReasonsNTC (N=1..4) textual-conventions are used
with the jmJobStateReasons1 object and jobStateReasonsN
(N=2..4), respectively, to provide additional information
regarding the current jmJobState object value.  These values
MAY be used with any job state or states for which the reason
makes sense.  See section 3.3.9.1 for the specification of each
bit value defined for use with the JmJobStateReasons1TC.

These bit definitions are the equivalent of a type 2 enum
except that combinations of bits may be used together.  See
section 3.7.1.2.

This textual-convention is used with the jobStateReasons2
attribute to provides additional information regarding the
jmJobState object.  See section 3.3.9.2 for the specification
of JmJobStateReasons2TC.  See section 3.3.9.1 for the
description under JmJobStateReasons1TC for additional
information that applies to all reasons.

These bit definitions are the equivalent of a type 2 enum
except that combinations of them may be used together.  See
section 3.7.1.2.

This textual-convention is used with the jobStateReasons3
attribute to provides additional information regarding the
jmJobState object.  See section 3.3.9.3 for the specification
of JmJobStateReasons3TC.  See section 3.3.9.1 for the
description under JmJobStateReasons1TC for additional
information that applies to all reasons.

These bit definitions are the equivalent of a type 2 enum
except that combinations of them may be used together.  See
section 3.7.1.2.

This textual-convention is used in the jobStateReasons4
attribute to provides additional information regarding the
jmJobState object.  See section 3.3.9.4 for the specification
of JmJobStateReasons4TC.  See section 3.3.9.1 for the
description under JmJobStateReasons1TC for additional
information that applies to all reasons.

These bit definitions are the equivalent of a type 2 enum
except that combinations of them may be used together.  See
section 3.7.1.2.

A period of time measured in units of .001 of seconds
when used in conjunction with the DISPLAY-HINT will
show seconds and fractions of second with a resolution
of .001 of a second.

A language tag, constructed in accordance with BCP 47.

Only lowercase characters are allowed.  The purpose of this
restriction is to provide unique language tags for use as
indexes.  BCP 47 recommends case conventions for user
interfaces, but objects using this TEXTUAL-CONVENTION MUST
use only lowercase.

Values MUST be well-formed language tags, in conformance
with the definition of well-formed tags in BCP 47.  An
implementation MAY further limit the values it accepts to
those permitted by a 'validating' processor, as defined in
BCP 47.

In theory, BCP 47 language tags are of unlimited length.
The language tag described in this TEXTUAL-CONVENTION is of
limited length.  The analysis of language tag lengths in BCP
47 confirms that this limit will not pose a problem in
practice.  In particular, this length is greater than the



minimum requirements set out in Section 4.3.1.

A zero-length language tag is not a valid language tag.
This can be used to express 'language tag absent' where
required, for example, when used as an index field.

LISP architecture can be applied to a wide variety of
address-families.  This textual-convention is a generalization
for representing addresses belonging to those address-families.
For convenience, this document refers to any such address as a
LISP address.  LispAddressType textual-convention consists of
the following four-tuple:
1. IANA Address Family Number: A field of length 2 octets,
   whose value is of the form following the assigned
   AddressFamilyNumbers textual-convention described in
   IANA-ADDRESS-FAMILY-NUMBERS-MIB DEFINITIONS, available from
   http://www.iana.org/assignments/ianaaddressfamilynumbers-mib.
   The enumerations are also listed in [IANA].  Note that this
   list of address family numbers is maintained by IANA.
2. Length of LISP address: A field of length 1 octet, whose
   value indicates the octet-length of the next (third)
   field of this LispAddressType four-tuple.
3. LISP address: A field of variable length as indicated in
   the previous (second) field, whose value is an address
   of the IANA Address Family indicated in the first field
   of this LispAddressType four-tuple.  Note that any of
   the IANA Address Families can be represented.
   Particularly when the address family is LISP Canonical
   Address Format (LCAF)
   with IANA-assigned Address Family Number 16387, then the
   first octet of this field indicates the LCAF type, and the
   rest of this field is same as the encoding format of the
   LISP Canonical Address after the length field, as defined
   in LCAF document.
4. Mask-length of address: A field of length 1 octet, whose
   value is the mask-length to be applied to the LISP
   address specified in the previous (third) field.

To illustrate the use of this object, consider the LISP MIB
Object below titled lispMapCacheEntry.  This object begins
with the following entities:

lispMapCacheEntry ::= SEQUENCE {
   lispMapCacheEidLength          INTEGER,
   lispMapCacheEid                LispAddressType,
    ... [skip] ...







Example 1: Suppose that the IPv4 EID-Prefix stored is
192.0.2.0/24.  In this case, the values within
lispMapCacheEntry would be:

   lispMapCacheEidLength  = 8
   lispMapCacheEid = 1, 4, 192.0.2.0, 24
   ... [skip] ...

where 8 is the total length in octets of the next object
(lispMapCacheEID of type LispAddressType).  Then, the value
1 indicates the IPv4 AF (per the
IANA-ADDRESS-FAMILY-NUMBERS-MIB), the value 4 indicates that
the AF is 4 octets in length, 192.0.2.0 is the IPv4 address,
and the value 24 is the mask-length in bits.  Note that the
lispMapCacheEidLength value of 8 is used to compute the
length of the fourth (last) field in lispMapCacheEid to be 1
octet -- as computed by 8 - (2 + 1 + 4) = 1.

Example 2: Suppose that the IPv6 EID-Prefix stored is
2001:db8:a::/48.  In this case, the values within
lispMapCacheEntry would be:

   lispMapCacheEidLength  = 20
   lispMapCacheEid = 2, 16, 2001:db8:a::, 48
   ... [skip] ...

where 20 is the total length in octets of the next object
(lispMapCacheEID of type LispAddressType).  Then, the value
2 indicates the IPv6 AF (per the
IANA-ADDRESS-FAMILY-NUMBERS-MIB), the value 16 indicates
that the AF is 16 octets in length, 2001:db8:a:: is the IPv6
address, and the value 48 is the mask-length in bits.  Note
that the lispMapCacheEidLength value of 20 is used to
compute the length of the fourth (last) field in
lispMapCacheEid to be 1 octet -- as computed by
20 - (2 + 1 + 16) = 1.

Example 3: As an example where LCAF is used, suppose
that the IPv4 EID-Prefix stored is 192.0.2.0/24 and it
is part of LISP Instance ID 101.  In this case, the values
within lispMapCacheEntry would be:

   lispMapCacheEidLength  = 11
   lispMapCacheEid = 16387, 7, 2, 101, 1, 192.0.2.0, 24
   ... [skip] ...






where 11 is the total length in octets of the next object
(lispMapCacheEID of type LispAddressType).  Then, the value
16387 indicates the LCAF AF (see the
IANA-ADDRESS-FAMILY-NUMBERS-MIB), the value 7 indicates that
the LCAF AF is 7 octets in length in this case, 2 indicates
that LCAF Type 2 encoding is used (see the LCAF document), 101
gives the Instance ID, 1 gives the AFI (per the
IANA-ADDRESS-FAMILY-NUMBERS-MIB) for an IPv4 address, 192.0.2.0
is the IPv4 address, and 24 is the mask-length in bits.  Note
that the lispMapCacheEidLength value of 11 octets is used to
compute the length of the last field in lispMapCacheEid to be 1
octet -- as computed by 11 - (2 + 1 + 1 + 1 + 1 + 4) = 1.

Note: all LISP header formats and locations of specific
flags, bits, and fields are as given in the base LISP
references of RFC 6830, RFC 6832, and RFC 6833.

The interval delay, in milliseconds.

The retransmission interval delay in milliseconds.

Represents a Node ID in network byte order.  Node ID is an
address of type IPv4.

********* THIS TC IS DEPRECATED **********

This TC has been deprecated in favour of
IANAifJackType.

Common enumeration values for repeater
and interface MAU jack types.

An indicator of the kind of NAT resources used by a policy
rule.  This definition corresponds to the definition of
NatBindMode in the NAT-MIB (RFC 4008).  Value none(3) can
be used to indicate that the policy rule does not use
any NAT binding.

A unique ID that is assigned to each NAT session by
a NAT implementation.  This definition corresponds to
the definition of NatSessionId in the NAT-MIB (RFC 4008).
Value 0 can be used to indicate that the policy rule does
not use any NAT binding.

This data type is used to define the registration
flags for Mobile IP registration extension:
   vjCompression
       -- Request to use VJ compression
   gre
       -- Request to use GRE
   minEnc
       -- Request to use minimal encapsulation
   decapsulationByMN
       -- Decapsulation by mobile node
   broadcastDatagram
       -- Request to receive broadcasts
   simultaneoursBindings
       -- Request to retain prior binding(s).

The value of the status field in the Binding
Acknowledgment message when the Binding Update
was rejected.

Index for an entry in mplsFTNTable.

Index for an entry in mplsFTNTable or the special value
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 when none or all
entries in mplsFTNTable need to be referenced.

An identifier that is assigned to each MPLS/BGP VPN and
is used to uniquely identify it.  This is assigned by the
system operator or NMS and SHOULD be unique throughout
the MPLS domain.  If this is the case, then this identifier
can then be used at any LSR within a specific MPLS domain
to identify this MPLS/BGP VPN.  It may also be possible to
preserve the uniqueness of this identifier across MPLS
domain boundaries, in which case this identifier can then
be used to uniquely identify MPLS/BGP VPNs on a more global
basis.  This object MAY be set to the VPN ID as defined in
RFC 2685.

Syntax for a route distinguisher and route target
as defined in [RFC4364].

Used to define the type of a route target usage.
Route targets can be specified to be imported,
exported, or both.  For a complete definition of a
route target, see [RFC4364].

This is an octet string that can be used as a table
index in cases where a large addressable space is
required such as on an LSR where many applications
may be provisioning labels.

Note that the string containing the single octet with
the value 0x00 is a reserved value used to represent
special cases. When this TEXTUAL-CONVENTION is used
as the SYNTAX of an object, the DESCRIPTION clause
MUST specify if this special value is valid and if so
what the special meaning is.

In systems that provide write access to the MPLS-LSR-STD
MIB, mplsIndexType SHOULD be used as a simple multi-digit
integer encoded as an octet string.
No further overloading of the meaning of an index SHOULD
be made.

In systems that do not offer write access to the MPLS-LSR-STD
MIB, the mplsIndexType may contain implicit formatting that is
specific to the implementation to convey additional
information such as interface index, physical card or
device, or application id. The interpretation of this
additional formatting is implementation dependent and
not covered in this document. Such formatting MUST



NOT impact the basic functionality of read-only access
to the MPLS-LSR-STD MIB by management applications that are
not aware of the formatting rules.