TOC 
Network Working GroupFebruary 13, 2014
Internet-Draft 
Intended status: Informational 
Expires: August 17, 2014 


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

Abstract

List of SMIv2 Textual Conventions. This file has been generated by smidump. Do not edit.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on August 17, 2014.

Copyright Notice

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.



Table of Contents

1.  IANA-ADDRESS-FAMILY-NUMBERS-MIB (revision 2002-03-14 00:00)
    1.1.  AddressFamilyNumbers
2.  IANA-CHARSET-MIB (revision 2011-10-30 00:00)
    2.1.  IANACharset
3.  IANA-ENTITY-MIB (revision 2013-04-05 00:00)
    3.1.  IANAPhysicalClass
4.  IANA-FINISHER-MIB (revision 2009-11-03 00:00)
    4.1.  FinDeviceTypeTC
    4.2.  FinAttributeTypeTC
    4.3.  FinEdgeTC
    4.4.  FinStitchingTypeTC
    4.5.  FinStitchingDirTypeTC
    4.6.  FinStitchingAngleTypeTC
    4.7.  FinFoldingTypeTC
    4.8.  FinBindingTypeTC
    4.9.  FinPunchHoleTypeTC
    4.10.  FinPunchPatternTC
    4.11.  FinSlittingTypeTC
    4.12.  FinWrappingTypeTC
    4.13.  FinStackOutputTypeTC
5.  IANA-GMPLS-TC-MIB (revision 2010-05-01 00:00)
    5.1.  IANAGmplsLSPEncodingTypeTC
    5.2.  IANAGmplsSwitchingTypeTC
    5.3.  IANAGmplsGeneralizedPidTC
    5.4.  IANAGmplsAdminStatusInformationTC
6.  IANAifType-MIB (revision 2012-05-17 00:00)
    6.1.  IANAifType
    6.2.  IANAtunnelType
7.  IANA-ITU-ALARM-TC-MIB (revision 2004-09-09 00:00)
    7.1.  IANAItuProbableCause
    7.2.  IANAItuEventType
8.  IANA-MALLOC-MIB (revision 2003-01-27 12:00)
    8.1.  IANAscopeSource
    8.2.  IANAmallocRangeSource
9.  IANA-MAU-MIB (revision 2011-08-12 00:00)
    9.1.  IANAifMauTypeListBits
    9.2.  IANAifMauMediaAvailable
    9.3.  IANAifMauAutoNegCapBits
    9.4.  IANAifJackType
10.  IANA-PRINTER-MIB (revision 2012-07-19 00:00)
    10.1.  PrtCoverStatusTC
    10.2.  PrtGeneralResetTC
    10.3.  PrtChannelTypeTC
    10.4.  PrtInterpreterLangFamilyTC
    10.5.  PrtInputTypeTC
    10.6.  PrtOutputTypeTC
    10.7.  PrtMarkerMarkTechTC
    10.8.  PrtMarkerSuppliesTypeTC
    10.9.  PrtMediaPathTypeTC
    10.10.  PrtConsoleColorTC
    10.11.  PrtConsoleDisableTC
    10.12.  PrtAlertTrainingLevelTC
    10.13.  PrtAlertGroupTC
    10.14.  PrtAlertCodeTC
11.  IANA-PWE3-MIB (revision 2009-06-11 00:00)
    11.1.  IANAPwTypeTC
    11.2.  IANAPwPsnTypeTC
    11.3.  IANAPwCapabilities
12.  IANA-RTPROTO-MIB (revision 2012-08-30 00:00)
    12.1.  IANAipRouteProtocol
    12.2.  IANAipMRouteProtocol
13.  IANATn3270eTC-MIB (revision 2000-05-10 00:00)
    13.1.  IANATn3270eAddrType
    13.2.  IANATn3270eAddress
    13.3.  IANATn3270eClientType
    13.4.  IANATn3270Functions
    13.5.  IANATn3270ResourceType
    13.6.  IANATn3270DeviceType
    13.7.  IANATn3270eLogData
14.  Security Considerations
§  Author's Address




 TOC 

1.  IANA-ADDRESS-FAMILY-NUMBERS-MIB (revision 2002-03-14 00:00)

The MIB module defines the AddressFamilyNumbers textual convention.



 TOC 

1.1.  AddressFamilyNumbers

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

The enumerations are described as:

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



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



 TOC 

2.  IANA-CHARSET-MIB (revision 2011-10-30 00:00)

This MIB module defines the IANACharset TEXTUAL-CONVENTION. The IANACharset TC is used to specify the encoding of string objects defined in a MIB. Each version of this MIB will be released based on the IANA Charset Registry file (see RFC 2978) at http://www.iana.org/assignments/character-sets. Note: The IANACharset TC, originally defined in RFC 1759, was inaccurately named CodedCharSet. Note: Best practice is to define new MIB string objects with invariant UTF-8 (RFC 3629) syntax using the SnmpAdminString TC (defined in RFC 3411) in accordance with IETF Policy on Character Sets and Languages (RFC 2277). Copyright (C) The Internet Society (2004). The initial version of this MIB module was published in RFC 3808; for full legal notices see the RFC itself. Supplementary information may be available on http://www.ietf.org/copyrights/ianamib.html.



 TOC 

2.1.  IANACharset

Specifies an IANA registered 'charset' - coded character set
(CCS) plus optional character encoding scheme (CES) - terms
defined in 'IANA Charset Registration Procedures' (RFC 2978).

Objects of this syntax are used to specify the encoding for
string objects defined in one or more MIBs.  For example, the
prtLocalizationCharacterSet, prtInterpreterDefaultCharSetIn, and
prtInterpreterDefaultCharSetOut objects defined in Printer MIB.

The current list of 'charset' names and enumerated values
is contained in the IANA Character Set Registry at:

   http://www.iana.org/assignments/character-sets

Enum names are derived from the IANA Charset Registry 'Alias'
fields that begin with 'cs' (for character set).
Enum values are derived from the parallel 'MIBenum' fields.



 TOC 

3.  IANA-ENTITY-MIB (revision 2013-04-05 00:00)

This MIB module defines a TEXTUAL-CONVENTION that provides an indication of the general hardware type of a particular physical entity. Copyright (c) 2013 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). The initial version of this MIB module was published in RFC 6933; for full legal notices see the RFC itself.



 TOC 

3.1.  IANAPhysicalClass

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

The enumeration 'energyObject' is applicable if the
physical entity is some sort of energy object, i.e.,
a piece of equipment that is part of or attached to
a communications network that is monitored, controlled,
or aids in the management of another device for Energy
Management.

The enumeration 'battery' is applicable if the physical
entity class is some sort of battery.



 TOC 

4.  IANA-FINISHER-MIB (revision 2009-11-03 00:00)

This MIB module defines a set of finishing-related TEXTUAL-CONVENTIONs for use in Finisher MIB (RFC 3806) and other MIBs which need to specify finishing mechanism details. Any additions or changes to the contents of this MIB module require either publication of an RFC, or Designated Expert Review as defined in RFC 2434, Guidelines for Writing an IANA Considerations Section in RFCs. The Designated Expert will be selected by the IESG Area Director(s) of the Applications Area. Copyright (C) The Internet Society (2004). The initial version of this MIB module was published in RFC 3806. For full legal notices see the RFC itself or see: http://www.ietf.org/copyrights/ianamib.html



 TOC 

4.1.  FinDeviceTypeTC

The defined finishing device subunit process
enumerations.



 TOC 

4.2.  FinAttributeTypeTC

This TEXTUAL-CONVENTION defines the set of enums for use in
the finDeviceAttributeTable.  See section 5.7 for the complete
specification of each attribute.



 TOC 

4.3.  FinEdgeTC

Specifies an edge for a Finishing Process.



 TOC 

4.4.  FinStitchingTypeTC

The defined stitching type enumerations.  For the edgeStitch and
stapleDual enums, the finReferenceEdge attribute is recommended

to define the edge to which the operation applies.



 TOC 

4.5.  FinStitchingDirTypeTC

Defines the direction, relative to the top sheet in the output
subunit, that the stitching operation was performed.  For a
topDown(3) process, the staple will be clinched on the bottom
of the stack.  This parameter can be used to determine what
order the pages of a booklet are to be printed such that the
staple clinch will be on the inside of the resulting booklet.



 TOC 

4.6.  FinStitchingAngleTypeTC

This enumeration provides a description of the angular
orientation of each stitch in a single or multiple stitching
operation, relative to the 'X' axis.  As with all finishing
operations, the 'X' axis is always relative to the portrait
orientation of the document regardless of the orientation
of the printed image.  This enum is primarily applicable to
corner stitching operations.



 TOC 

4.7.  FinFoldingTypeTC

The defined folding device process enumerations.



 TOC 

4.8.  FinBindingTypeTC

The defined binding type enumerations.



 TOC 

4.9.  FinPunchHoleTypeTC

The defined hole type punch process enumerations.



 TOC 

4.10.  FinPunchPatternTC

The defined hole pattern punch process enumerations.



 TOC 

4.11.  FinSlittingTypeTC

The defined slitting type enumerations.



 TOC 

4.12.  FinWrappingTypeTC

The defined wrapping device process enumerations.



 TOC 

4.13.  FinStackOutputTypeTC

The defined stack output type enumerations.



 TOC 

5.  IANA-GMPLS-TC-MIB (revision 2010-05-01 00:00)

Copyright (C) The IETF Trust (2007). The initial version of this MIB module was published in RFC 4802. For full legal notices see the RFC itself. Supplementary information may be available on: http://www.ietf.org/copyrights/ianamib.html



 TOC 

5.1.  IANAGmplsLSPEncodingTypeTC

This type is used to represent and control
the LSP encoding type of an LSP signaled by a GMPLS
signaling protocol.

This textual convention is strongly tied to the LSP
Encoding Types sub-registry of the GMPLS Signaling
Parameters registry managed by IANA.  Values should be
assigned by IANA in step with the LSP Encoding Types
sub-registry and using the same registry management rules.
However, the actual values used in this textual convention
are solely within the purview of IANA and do not
necessarily match the values in the LSP Encoding Types
sub-registry.

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



 TOC 

5.2.  IANAGmplsSwitchingTypeTC

This type is used to represent and
control the LSP switching type of an LSP signaled by a
GMPLS signaling protocol.

This textual convention is strongly tied to the Switching
Types sub-registry of the GMPLS Signaling Parameters
registry managed by IANA.  Values should be assigned by
IANA in step with the Switching Types sub-registry and
using the same registry management rules.  However, the
actual values used in this textual convention are solely
within the purview of IANA and do not necessarily match
the values in the Switching Types sub-registry.

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



 TOC 

5.3.  IANAGmplsGeneralizedPidTC

This data type is used to represent and control the LSP
Generalized Protocol Identifier (G-PID) of an LSP
signaled by a GMPLS signaling protocol.

This textual convention is strongly tied to the Generalized
PIDs (G-PID) sub-registry of the GMPLS Signaling Parameters
registry managed by IANA.  Values should be assigned by
IANA in step with the Generalized PIDs (G-PID) sub-registry
and using the same registry management rules.  However, the
actual values used in this textual convention are solely
within the purview of IANA and do not necessarily match the
values in the Generalized PIDs (G-PID) sub-registry.

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



 TOC 

5.4.  IANAGmplsAdminStatusInformationTC

This data type determines the setting of the
Admin Status flags in the Admin Status object or TLV, as
described in RFC 3471.  Setting this object to a non-zero
value will result in the inclusion of the Admin Status

object or TLV on signaling messages.

This textual convention is strongly tied to the
Administrative Status Information Flags sub-registry of
the GMPLS Signaling Parameters registry managed by IANA.
Values should be assigned by IANA in step with the
Administrative Status Flags sub-registry and using the
same registry management rules.  However, the actual
values used in this textual convention are solely
within the purview of IANA and do not necessarily match
the values in the Administrative Status Information
Flags sub-registry.

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



 TOC 

6.  IANAifType-MIB (revision 2012-05-17 00:00)

This MIB module defines the IANAifType Textual Convention, and thus the enumerated values of the ifType object defined in MIB-II's ifTable.



 TOC 

6.1.  IANAifType

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

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

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

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



 TOC 

6.2.  IANAtunnelType

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

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

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

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



 TOC 

7.  IANA-ITU-ALARM-TC-MIB (revision 2004-09-09 00:00)

The MIB module defines the ITU Alarm textual convention for objects expected to require regular extension. Copyright (C) The Internet Society (2004). The initial version of this MIB module was published in RFC 3877. For full legal notices see the RFC itself. Supplementary information may be available on: http://www.ietf.org/copyrights/ianamib.html



 TOC 

7.1.  IANAItuProbableCause

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



 TOC 

7.2.  IANAItuEventType

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



 TOC 

8.  IANA-MALLOC-MIB (revision 2003-01-27 12:00)

This MIB module defines the IANAscopeSource and IANAmallocRangeSource textual conventions for use in MIBs which need to identify ways of learning multicast scope and range information. Any additions or changes to the contents of this MIB module require either publication of an RFC, or Designated Expert Review as defined in the Guidelines for Writing IANA Considerations Section document. The Designated Expert will be selected by the IESG Area Director(s) of the Transport Area.



 TOC 

8.1.  IANAscopeSource

The source of multicast scope information.



 TOC 

8.2.  IANAmallocRangeSource

The source of multicast address allocation range
information.



 TOC 

9.  IANA-MAU-MIB (revision 2011-08-12 00:00)

This MIB module defines dot3MauType OBJECT-IDENTITIES and IANAifMauListBits, IANAifMauMediaAvailable, IANAifMauAutoNegCapBits, and IANAifJackType TEXTUAL-CONVENTIONs, specifying enumerated values of the ifMauTypeListBits, ifMauMediaAvailable / rpMauMediaAvailable, ifMauAutoNegCapabilityBits / ifMauAutoNegCapAdvertisedBits / ifMauAutoNegCapReceivedBits and ifJackType / rpJackType objects respectively, defined in the MAU-MIB. It is intended that each new MAU type, Media Availability state, Auto Negotiation capability and/or Jack type defined by the IEEE 802.3 working group and approved for publication in a revision of IEEE Std 802.3 will be added to this MIB module, provided that it is suitable for being managed by the base objects in the MAU-MIB. An Expert Review, as defined in RFC 2434 [RFC2434], is REQUIRED for such additions. The following reference is used throughout this MIB module: [IEEE802.3] refers to: IEEE Std 802.3, 2005 Edition: 'IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications'. This reference should be updated as appropriate when new MAU types, Media Availability states, Auto Negotiation capabilities, and/or Jack types are added to this MIB module. Copyright (C) The IETF Trust (2007). The initial version of this MIB module was published in RFC 4836; for full legal notices see the RFC itself. Supplementary information may be available at: http://www.ietf.org/copyrights/ianamib.html



 TOC 

9.1.  IANAifMauTypeListBits

This data type is used as the syntax of the ifMauTypeListBits
object in the (updated) definition of MAU-MIB's ifMauTable.

The most recent version of this textual convention is available
in the online version of this MIB module on the IANA web site.

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

Note that changes in this textual convention SHALL be
synchronized with relevant changes in the dot3MauType
OBJECT-IDENTITIES.



 TOC 

9.2.  IANAifMauMediaAvailable

This data type is used as the syntax of the
ifMauMediaAvailable and rpMauMediaAvailable objects in the
(updated) definition of MAU-MIB's ifMauTable and rpMauTable
respectively.

Possible values are:
  other(1)             - undefined (not listed below)
  unknown(2)           - MAU's true state is unknown; e.g.,
                         during initialization
  available(3)         - link, light, or loopback is normal
  notAvailable(4)      - link loss, low light, or no loopback
  remoteFault(5)       - a fault has been detected at the
                         remote end of the link.  This value
                         applies to 10BASE-FB, 100BASE-T4 Far
                         End Fault Indication and non-specified
                         remote faults from a system running
                         auto-negotiation
  invalidSignal(6)     - invalid signal has been received from
                         the other end of the link, 10BASE-FB
                         only
  remoteJabber(7)      - remote fault, due to jabber

  remoteLinkLoss(8)    - remote fault, due to link loss
  remoteTest(9)        - remote fault, due to test
  offline(10)          - offline, Clause 37 Auto-Negotiation
                         only
  autoNegError(11)     - Auto-Negotiation Error, Clause 37
                         Auto-Negotiation only
  pmdLinkFault(12)     - PMA/PMD receive link fault.  In case
                         of PAF (2BASE-TL / 10PASS-TS PHYs),
                         all PMEs in the aggregation group have
                         detected a link fault
  wisFrameLoss(13)     - WIS loss of frame, 10GBASE-W only
  wisSignalLoss(14)    - WIS loss of signal, 10GBASE-W only
  pcsLinkFault(15)     - PCS receive link fault
  excessiveBER(16)     - PCS Bit Error Ratio monitor
                         reporting excessive error ratio
  dxsLinkFault(17)     - DTE XGXS receive link fault, XAUI only
  pxsLinkFault(18)     - PHY XGXS receive link fault, XAUI only
  availableReduced(19) - link normal, reduced bandwidth,
                         2BASE-TL / 10PASS-TS only
  ready(20)            - at least one PME in the aggregation
                         group is detecting handshake tones,
                         2BASE-TL / 10PASS-TS only

If the MAU is a 10M b/s link or fiber type (FOIRL, 10BASE-T,
10BASE-F), then this is equivalent to the link test fail
state/low light function.  For an AUI, 10BASE2, 10BASE5, or
10BROAD36 MAU, this indicates whether loopback is detected on
the DI circuit.  The value of this attribute persists between
packets for MAU types AUI, 10BASE5, 10BASE2, 10BROAD36, and
10BASEFP.

At power-up or following a reset, the Media Available state
will be unknown(2) for AUI, 10BASE5, 10BASE2, 10BROAD36, and
10BASE-FP MAUs.  For these MAUs loopback will be tested on each
transmission during which no collision is detected.
If DI is receiving input when DO returns to IDL after a
transmission and there has been no collision during the
transmission, then loopback will be detected.  The Media
Available state will only change during noncollided
transmissions for AUI, 10BASE2, 10BASE5, 10BROAD36, and
10BASE-FP MAUs.

For 100BASE-T2, 100BASE-T4, 100BASE-TX, 100BASE-FX,
100BASE-LX10, and 100BASE-BX10 PHYs the enumerations match the
states within the link integrity state diagram.
Any MAU that implements management of [IEEE802.3] Clause
28 Auto-Negotiation, will map remote fault indication to
remoteFault(5).

Any MAU that implements management of Clause 37
Auto-Negotiation, will map the received RF1 and RF2 bits as
follows: Offline maps to offline(10), Link_Failure maps to
remoteFault(5), and Auto-Negotiation Error maps to
autoNegError(11).

The value remoteFault(5) applies to 10BASE-FB remote
fault indication, the 100BASE-X far-end fault indication, and
nonspecified remote faults from a system running Clause 28
Auto-Negotiation.

The value remoteJabber(7), remoteLink loss(8), or remoteTest(9)
SHOULD be used instead of remoteFault(5) where the reason for
remote fault is identified in the remote signaling protocol.
Where a Clause 22 MII or Clause 35 GMII is present, a logic
one in the remote fault bit maps to the value remoteFault(5),
a logic zero in the link status bit maps to the enumeration
notAvailable(4).  The value notAvailable(4) takes precedence
over remoteFault(5).

For 2BASE-TL and 10PASS-TS PHYs, the value unknown(2) maps to
the condition where the PHY (PCS with connected PMEs) is
initializing, the value ready(20) maps to the condition where
the interface is down and at least one PME in the aggregation
group is ready for handshake, the value available(3) maps to
the condition where all the PMEs in the aggregation group are
up, the value notAvailable(4) maps to the condition where all
the PMEs in the aggregation group are down and no handshake
tones are detected, the value availableReduced(19) maps to the
condition where the interface is up, a link fault is detected
at the receive direction by one or more PMEs in the
aggregation group, but at least one PME is up and the
enumeration pmdLinkFault(12) maps to the condition where a link
fault is detected at the receive direction by all of the PMEs
in the aggregation group.

For 10 Gb/s the enumerations map to value of the link_fault
variable within the Link Fault Signaling state diagram
as follows: the value OK maps to the value available(3),
the value Local Fault maps to the value notAvailable(4),
and the value Remote Fault maps to the value remoteFault(5).
The value pmdLinkFault(12), wisFrameLoss(13),
wisSignalLoss(14), pcsLinkFault(15), excessiveBER(16), or
dxsLinkFault(17) SHOULD be used instead of the value
notAvailable(4), where the reason for the Local Fault state can
be identified through the use of the Clause 45 MDIO Interface.
Where multiple reasons for the Local Fault state can be
identified, only the highest precedence error SHOULD be

reported.  This precedence in descending order is as follows:

  pxsLinkFault
  pmdLinkFault
  wisFrameLoss
  wisSignalLoss
  pcsLinkFault
  excessiveBER
  dxsLinkFault.

Where a Clause 45 MDIO interface is present a logic zero in
the PMA/PMD Receive link status bit ([IEEE802.3]
Section 45.2.1.2.2) maps to the value pmdLinkFault(12),
logic one in the LOF status bit (Section 45.2.2.10.4) maps
to the value wisFrameLoss(13), a logic one in the LOS
status bit (Section 45.2.2.10.5) maps to the value
wisSignalLoss, a logic zero in the PCS Receive
link status bit (Section 45.2.3.2.2) maps to the value
pcsLinkFault(15), a logic one in the 10GBASE-R PCS Latched
high BER status bit (Section 45.2.3.12.2) maps to the value
excessiveBER, a logic zero in the DTE XS receive link status
bit (Section 45.2.5.2.2) maps to the value dxsLinkFault(17)
and a logic zero in the PHY XS transmit link status bit
(Section 45.2.4.2.2) maps to the value pxsLinkFault(18).

The most recent version of this textual convention is available
in the online version of this MIB module on the IANA web site.

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



 TOC 

9.3.  IANAifMauAutoNegCapBits

This data type is used as the syntax of the
ifMauAutoNegCapabilityBits, ifMauAutoNegCapAdvertisedBits, and
ifMauAutoNegCapReceivedBits objects in the (updated) definition
of MAU-MIB's ifMauAutoNegTable.

The most recent version of this textual convention is available
in the online version of this MIB module on the IANA web site.

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



 TOC 

9.4.  IANAifJackType

Common enumeration values for repeater and interface MAU
jack types.  This data type is used as the syntax of the
ifJackType and rpJackType objects in the (updated) definition
of MAU-MIB's ifJackTable and rpJackTable respectively.

Possible values are:
     other(1)          - undefined or unknown
     rj45(2)           - RJ45
     rj45S(3)          - RJ45 shielded
     db9(4)            - DB9
     bnc(5)            - BNC
     fAUI(6)           - AUI female
     mAUI(7)           - AUI male
     fiberSC(8)        - SC fiber
     fiberMIC(9)       - MIC fiber
     fiberST(10)       - ST fiber
     telco(11)         - Telco
     mtrj(12)          - MT-RJ fiber
     hssdc(13)         - fiber channel style-2
     fiberLC(14)       - LC fiber
     cx4(15)           - IB4X for 10GBASE-CX4

The most recent version of this textual convention is available
in the online version of this MIB module on the IANA web site.

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



 TOC 

10.  IANA-PRINTER-MIB (revision 2012-07-19 00:00)

This MIB module defines a set of printing-related TEXTUAL-CONVENTIONs for use in Printer MIB (RFC 3805), Finisher MIB (RFC 3806), and other MIBs which need to specify printing mechanism details. Any additions or changes to the contents of this MIB module require either publication of an RFC, or Designated Expert Review as defined in RFC 2434, Guidelines for Writing an IANA Considerations Section in RFCs. The Designated Expert will be selected by the IESG Area Director(s) of the Applications Area. Copyright (C) The Internet Society (2004). The initial version of this MIB module was published in RFC 3805. For full legal notices see the RFC itself or see: http://www.ietf.org/copyrights/ianamib.html



 TOC 

10.1.  PrtCoverStatusTC

Values for encoding the state of a particular cover or
access panel on the printer case or enclosure.



 TOC 

10.2.  PrtGeneralResetTC

Values for reading and writing the prtGeneralReset object.

If a device does not have NVRAM, the device shall none the
less respond to a SET with the value resetToNVRAM(5) with a
sort of warm reset that resets the device to implementation-
defined state that is preferably under control of the system
administrator by some means outside the scope of the Printer
MIB specification.



 TOC 

10.3.  PrtChannelTypeTC

This enumeration indicates the type of channel that is
receiving jobs.



 TOC 

10.4.  PrtInterpreterLangFamilyTC

This enumeration indicates the type of interpreter that is
receiving jobs.



 TOC 

10.5.  PrtInputTypeTC

The type of technology (discriminated primarily according to
feeder mechanism type) employed by a specific component or
components.



 TOC 

10.6.  PrtOutputTypeTC

The Type of technology supported by this output subunit.



 TOC 

10.7.  PrtMarkerMarkTechTC

The type of marking technology used for this marking
subunit.



 TOC 

10.8.  PrtMarkerSuppliesTypeTC

The type of this supply.



 TOC 

10.9.  PrtMediaPathTypeTC

The type of the media path for this media path.



 TOC 

10.10.  PrtConsoleColorTC

The color of this light.



 TOC 

10.11.  PrtConsoleDisableTC

This value indicates whether or not input is accepted from
the operator console.  A value of 'enabled' indicates that
input is accepted from the console, and a value of 'disabled'
indicates that input is not accepted from the console.



 TOC 

10.12.  PrtAlertTrainingLevelTC

The level of training required to handle this alert, if
human intervention is required.  The noInterventionRequired
value should be used if the event does not require any human
intervention.  The training level is an enumeration that is
determined and assigned by the printer manufacturer based on
the information or training required to handle this alert.
The printer will break alerts into these different training
levels.  It is the responsibility of a management application
in the system to determine how a particular alert is handled
and how and to whom that alert is routed.  The following are
the four training levels of alerts:

Field Service - Alerts that typically require advanced
    training and technical knowledge of the printer and its
    subunits.  An example of a technical person would be a
    manufacturer's Field Service representative, or other
    person formally trained by the manufacturer or similar
    representative.
Trained - Alerts that require an intermediate or moderate
    knowledge of the printer and its subunits.  A typical
    example of such an alert is replacing a toner cartridge.
Untrained -     Alerts that can be fixed without prior
    training either because the action to correct the alert
    is obvious or the printer can help the untrained person
    fix the problem.  A typical example of such an alert is
    reloading paper trays or emptying output bins on a low
    end printer.
Management -    Alerts that have to do with overall operation
    of and configuration of the printer.  Examples of such
    management events are configuration change of subunits.



 TOC 

10.13.  PrtAlertGroupTC

The type of subunit within the printer model that this alert
is related.  Input, output, and markers are examples of
printer model groups, i.e., examples of types of subunits.
Wherever possible, the enumerations match the sub-identifier
that identifies the relevant table in the Printer MIB.

NOTE: Alert type codes have been added for the Host Resources
MIB storage table and device table.  These additional types
are for situations in which the printer's storage and device
objects must generate alerts (and possibly traps for critical
alerts).



 TOC 

10.14.  PrtAlertCodeTC

The code that describes the type of alert for this entry in

the table.  Binary change event alerts describe states of the
subunit while unary change event alerts describe a single
event.  The same alert code can be used for a binary change
event or a unary change event, depending on implementation.
Also, the same alert code can be used to indicate a critical
or non-critical (warning) alert, depending on implementation.
The value of prtAlertSeverityLevel specifies binary vs. unary
and critical vs. non-critical for each event for the
implementation.

While there are some specific codes for many subunits, the
generic codes should be used for most subunit alerts.  The
network management station can then query the subunit
specified by prtAlertGroup to determine further subunit
status and other subunit information.

An agent shall not add two entries to the alert table for the
same event, one containing a generic event code and the other
containing a specific event code; the agent shall add only
one entry in the alert table for each event; either generic
(preferred) or specific, not both.

Implementation of the unary change event
alertRemovalOfBinaryChangeEntry(1801) is optional.  When
implemented, this alert code shall indicate to network
management stations that the trailing edge of a binary change
event has occurred and the corresponding alert entry has been
removed from the alert table.  As with all events, the
alertRemovalOfBinaryChangeEntry(1801) alert shall be placed
at the end of the alert table.  Such an alert table entry
shall specify the following information:

prtAlertSeverityLevel   warningUnaryChangeEvent(4)
prtAlertTrainingLevel   noInterventionRequired(7)
prtAlertGroup           alert(18)
prtAlertGroupIndex      the index of the row in the
                        alert table of the binary
                        change event that this event
                        has removed.
prtAlertLocation        unknown (-2)
prtAlertCode            alertRemovalOfBinaryChangeEntry(1801)
prtAlertDescription     <description or null string>
prtAlertTime            the value of sysUpTime at
                        the time of the removal of the
                        binary change event from the
                        alert table.

Optionally, the agent may generate a trap coincident with

removing the binary change event and placing the unary change
event alertRemovalOfBinaryChangeEntry(1801) in the alert
table.  For such a trap, the prtAlertIndex sent with the above
trap parameters shall be the index of the
alertRemovalOfBinaryChangeEvent row that was added to the
prtAlertTable; not the index of the row that was removed from
the prtAlertTable.



 TOC 

11.  IANA-PWE3-MIB (revision 2009-06-11 00:00)

This MIB module defines the IANAPwTypeTC and IANAPwPsnTypeTC textual conventions for use in PWE3 MIB modules. Any additions or changes to the contents of this MIB module require either publication of an RFC, Designated Expert Review as defined in RFC 5226, Guidelines for Writing an IANA Considerations Section in RFCs, and should be based on the procedures defined in [RFC4446]. The Designated Expert will be selected by the IESG Area Director(s) of the internet Area. Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. - Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.



 TOC 

11.1.  IANAPwTypeTC

Indicates the PW type (i.e., the carried service).



 TOC 

11.2.  IANAPwPsnTypeTC

Identifies the PSN type that the PW will use over the
network.



 TOC 

11.3.  IANAPwCapabilities

This TC describes a collection of capabilities related to
a specific PW.
Values may be added in the future based on new capabilities
introduced in IETF documents.



 TOC 

12.  IANA-RTPROTO-MIB (revision 2012-08-30 00:00)

This MIB module defines the IANAipRouteProtocol and IANAipMRouteProtocol textual conventions for use in MIBs which need to identify unicast or multicast routing mechanisms. Any additions or changes to the contents of this MIB module require either publication of an RFC, or Designated Expert Review as defined in RFC 2434, Guidelines for Writing an IANA Considerations Section in RFCs. The Designated Expert will be selected by the IESG Area Director(s) of the Routing Area.



 TOC 

12.1.  IANAipRouteProtocol

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



 TOC 

12.2.  IANAipMRouteProtocol

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



 TOC 

13.  IANATn3270eTC-MIB (revision 2000-05-10 00:00)

This module defines a set of textual conventions for use by the TN3270E-MIB and the TN3270E-RT-MIB. Any additions or changes to the contents of this MIB module must first be discussed on the tn3270e working group list at: tn3270e@list.nih.gov and approved by one of the following TN3270E working group contacts: Ed Bailey (co-chair) - elbailey@us.ibm.com Michael Boe (co-chair) - mboe@cisco.com Ken White - kennethw@vnet.ibm.com Robert Moore - remoore@us.ibm.com The above list of contacts can be altered with the approval of the two co-chairs. The Textual Conventions defined within this MIB have no security issues associated with them unless explicitly stated in their corresponding DESCRIPTION clause.



 TOC 

13.1.  IANATn3270eAddrType

The textual convention for defining the type of a
client address.  The enumeration value unknown(0) is
also used to indicate that no actual address is present.



 TOC 

13.2.  IANATn3270eAddress

Denotes a client address.  The type of client address is
determined by use of the IANATn3270eAddrType textual
convention.
The length in octets of a IANATn3270eAddress object is:

  IANATn3270eAddrType   Address Length
  +++++++++++++++++++   ++++++++++++++
           unknown(0)   not specified or unknown; the
                        actual length of the
                        IANATn3270eAddress octet string
                        indicates if an address
                        is present
              ipv4(1)   4 OCTETS
              ipv6(2)   16 OCTETS

This textual convention is similar to the TAddress
TC defined by RFC1903 except that it allows a
zero-length octet string and is not a full transport
layer address.



 TOC 

13.3.  IANATn3270eClientType

The textual convention for defining the set of
enumerations used by tn3270eTcpConnClientIdFormat
in the TN3270E-MIB:

ENUMERATION        OCTETs  DESCRIPTION

none(1)              0     Not specified
other(2)           1..512  Implementation specific
ipv4(3)              6     4-octet IP Address plus
                           2-octet TCP Port
ipv6(4)              18    16-octet IPv6 Address
                           plus 2-octet TCP Port
domainName(5)      1..512  The DNS name of a
                           client.
truncDomainName(6) 1..512  The (truncated) DNS name
                           of a client.
string(7)          1..512  Unknown Utf8String
certificate(8)     1..512  certificate
userId(9)          1..8    Client's userid
x509dn(10)         1..512  X.509 Distinguished Name

Representation of a certificate(8) may be lead to
a security exposure and is NOT RECOMMENDED without
adequate security.



 TOC 

13.4.  IANATn3270Functions

This textual convention reflects the current set of
TN3270 and TN3270E functions that can be negotiated
between a server and its client:

RFC856
transmitBinary  The sender of this command REQUESTS
                permission to begin transmitting, or
                confirms that it will now begin
                transmitting characters which are to
                be interpreted as 8 bits of binary
                data by the receiver of the data.
RFC860
timingMark      The sender of this command REQUESTS
                that the receiver of this command
                return a WILL TIMING-MARK in the data
                stream at the 'appropriate place'.
RFC885
endOfRecord     The sender of this command requests
                permission to begin transmission of
                the Telnet END-OF-RECORD (EOR) code
                when transmitting data characters, or
                the sender of this command confirms it
                will now begin transmission of EORs
                with transmitted data characters.
RFC1091
terminalType    Sender is willing to send terminal
                type information in a subsequent
                sub-negotiation.

RFC1041
tn3270Regime    Sender is willing to send list of
                supported 3270 Regimes in a
                subsequent sub-negotiation.
RFC2355
scsCtlCodes     (Printer sessions only).  Allows the
                use of the SNA Character Stream (SCS)
                and SCS control codes on the session.
                SCS is used with LU type 1 SNA sessions.
dataStreamCtl   (Printer sessions only).  Allows the use
                of the standard 3270 data stream.  This
                corresponds to LU type 3 SNA sessions.
responses       Provides support for positive and
                negative response handling.  Allows the
                server to reflect to the client any and
                all definite, exception, and no response
                requests sent by the host application.
bindImage       Allows the server to send the SNA Bind
                image and Unbind notification to the
                client.
sysreq          Allows the client and server to emulate
                some (or all, depending on the server) of
                the functions of the SYSREQ key in an SNA
                environment.



 TOC 

13.5.  IANATn3270ResourceType

The type of resource defined by a resource pool.  Refer
to tn3270eResPoolTable.



 TOC 

13.6.  IANATn3270DeviceType

This textual convention defines the list of device
types that can be set, as defined by RFC 2355.



 TOC 

13.7.  IANATn3270eLogData

An octet string representing log data as pertaining to
either a TN3270 or TN3270E Session as reported from a
TN3270E Server. Log data is stored in an octet string
in time order (from earliest to latest).

Each log element has the following form:

+------+----+---------+------------+
!length!type!TimeStamp! data       !
+------+----+---------+------------+

where

length    = one-octet length of the data portion of the
            trace element, not including the length,
            type, and TimeStamp fields
type      = one-octet code point characterizing the data.
TimeStamp = A 4-octet field representing the number of
            TimeTicks since the TN3270E server was last
            activated.  The server's last activation time
            is available in the tn3270eSrvrConfLastActTime
            object in the TN3270E MIB, which has the
            syntax DateAndTime.
data      = initial part of a PDU.

length   type

  0-255  x'00' - unknown
  0      x'01' - inactivity timer expired
  0      x'02' - dynamic timer expired
  0      x'03' - actlu req
  0      x'04' - bind req
  0      x'05' - clear req
  0      x'06' - dactlu req
  0      x'07' - warm actpu req
  0      x'08' - sdt req
  0      x'09' - unbind req
  0      x'0A' - notify resp
  0      x'0B' - reply PSID neg rsp
  0      x'0C' - reply PSID pos rsp
  0      x'0D' - unbind rsp
  0      x'0E' - hierarchical reset
  0      x'0F' - client connect req
  0      x'10' - client disconnect req
  0      x'11' - timingmark received
  0      x'12' - flowControl timer expired
  0      x'13' - neg rsp to host
  0      x'14' - neg rsp from host
  0      x'15' - data contention
  0      x'16' - no buffer to send SNA data
  0      x'17' - receive response while inbound
  0      x'18' - client protocol error
  0      x'19' - badClientSequenceReceived
  1-255  x'1A' - utf8String
  2      x'1B' - hexCode, implementation dependent

  Log element entries have a minimum length of 6 octets.
  The zero-length string indicates that no log data is
  available.



 TOC 

14.  Security Considerations

None.



 TOC 

Author's Address