Network Working Group February 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 Expires August 17, 2014 [Page 1] Internet-Draft SMIv2 Textual Conventions February 2014 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) . 4 1.1. AddressFamilyNumbers . . . . . . . . . . . . . . . . . . 4 2. IANA-CHARSET-MIB (revision 2011-10-30 00:00) . . . . . . . . . 6 2.1. IANACharset . . . . . . . . . . . . . . . . . . . . . . . 6 3. IANA-ENTITY-MIB (revision 2013-04-05 00:00) . . . . . . . . . 6 3.1. IANAPhysicalClass . . . . . . . . . . . . . . . . . . . . 7 4. IANA-FINISHER-MIB (revision 2009-11-03 00:00) . . . . . . . . 9 4.1. FinDeviceTypeTC . . . . . . . . . . . . . . . . . . . . . 9 4.2. FinAttributeTypeTC . . . . . . . . . . . . . . . . . . . 9 4.3. FinEdgeTC . . . . . . . . . . . . . . . . . . . . . . . . 9 4.4. FinStitchingTypeTC . . . . . . . . . . . . . . . . . . . 9 4.5. FinStitchingDirTypeTC . . . . . . . . . . . . . . . . . . 9 4.6. FinStitchingAngleTypeTC . . . . . . . . . . . . . . . . . 10 4.7. FinFoldingTypeTC . . . . . . . . . . . . . . . . . . . . 10 4.8. FinBindingTypeTC . . . . . . . . . . . . . . . . . . . . 10 4.9. FinPunchHoleTypeTC . . . . . . . . . . . . . . . . . . . 10 4.10. FinPunchPatternTC . . . . . . . . . . . . . . . . . . . . 10 4.11. FinSlittingTypeTC . . . . . . . . . . . . . . . . . . . . 10 4.12. FinWrappingTypeTC . . . . . . . . . . . . . . . . . . . . 10 4.13. FinStackOutputTypeTC . . . . . . . . . . . . . . . . . . 10 5. IANA-GMPLS-TC-MIB (revision 2010-05-01 00:00) . . . . . . . . 11 5.1. IANAGmplsLSPEncodingTypeTC . . . . . . . . . . . . . . . 11 5.2. IANAGmplsSwitchingTypeTC . . . . . . . . . . . . . . . . 11 5.3. IANAGmplsGeneralizedPidTC . . . . . . . . . . . . . . . . 12 5.4. IANAGmplsAdminStatusInformationTC . . . . . . . . . . . . 13 6. IANAifType-MIB (revision 2012-05-17 00:00) . . . . . . . . . . 14 6.1. IANAifType . . . . . . . . . . . . . . . . . . . . . . . 14 6.2. IANAtunnelType . . . . . . . . . . . . . . . . . . . . . 15 7. IANA-ITU-ALARM-TC-MIB (revision 2004-09-09 00:00) . . . . . . 16 7.1. IANAItuProbableCause . . . . . . . . . . . . . . . . . . 16 7.2. IANAItuEventType . . . . . . . . . . . . . . . . . . . . 17 8. IANA-MALLOC-MIB (revision 2003-01-27 12:00) . . . . . . . . . 18 8.1. IANAscopeSource . . . . . . . . . . . . . . . . . . . . . 18 8.2. IANAmallocRangeSource . . . . . . . . . . . . . . . . . . 18 9. IANA-MAU-MIB (revision 2011-08-12 00:00) . . . . . . . . . . . 18 Expires August 17, 2014 [Page 2] Internet-Draft SMIv2 Textual Conventions February 2014 9.1. IANAifMauTypeListBits . . . . . . . . . . . . . . . . . . 19 9.2. IANAifMauMediaAvailable . . . . . . . . . . . . . . . . . 19 9.3. IANAifMauAutoNegCapBits . . . . . . . . . . . . . . . . . 22 9.4. IANAifJackType . . . . . . . . . . . . . . . . . . . . . 22 10. IANA-PRINTER-MIB (revision 2012-07-19 00:00) . . . . . . . . . 23 10.1. PrtCoverStatusTC . . . . . . . . . . . . . . . . . . . . 23 10.2. PrtGeneralResetTC . . . . . . . . . . . . . . . . . . . . 24 10.3. PrtChannelTypeTC . . . . . . . . . . . . . . . . . . . . 24 10.4. PrtInterpreterLangFamilyTC . . . . . . . . . . . . . . . 24 10.5. PrtInputTypeTC . . . . . . . . . . . . . . . . . . . . . 24 10.6. PrtOutputTypeTC . . . . . . . . . . . . . . . . . . . . . 24 10.7. PrtMarkerMarkTechTC . . . . . . . . . . . . . . . . . . . 24 10.8. PrtMarkerSuppliesTypeTC . . . . . . . . . . . . . . . . . 24 10.9. PrtMediaPathTypeTC . . . . . . . . . . . . . . . . . . . 25 10.10. PrtConsoleColorTC . . . . . . . . . . . . . . . . . . . . 25 10.11. PrtConsoleDisableTC . . . . . . . . . . . . . . . . . . . 25 10.12. PrtAlertTrainingLevelTC . . . . . . . . . . . . . . . . . 25 10.13. PrtAlertGroupTC . . . . . . . . . . . . . . . . . . . . . 26 10.14. PrtAlertCodeTC . . . . . . . . . . . . . . . . . . . . . 27 11. IANA-PWE3-MIB (revision 2009-06-11 00:00) . . . . . . . . . . 28 11.1. IANAPwTypeTC . . . . . . . . . . . . . . . . . . . . . . 29 11.2. IANAPwPsnTypeTC . . . . . . . . . . . . . . . . . . . . . 29 11.3. IANAPwCapabilities . . . . . . . . . . . . . . . . . . . 29 12. IANA-RTPROTO-MIB (revision 2012-08-30 00:00) . . . . . . . . . 29 12.1. IANAipRouteProtocol . . . . . . . . . . . . . . . . . . . 29 12.2. IANAipMRouteProtocol . . . . . . . . . . . . . . . . . . 29 13. IANATn3270eTC-MIB (revision 2000-05-10 00:00) . . . . . . . . 30 13.1. IANATn3270eAddrType . . . . . . . . . . . . . . . . . . . 30 13.2. IANATn3270eAddress . . . . . . . . . . . . . . . . . . . 30 13.3. IANATn3270eClientType . . . . . . . . . . . . . . . . . . 30 13.4. IANATn3270Functions . . . . . . . . . . . . . . . . . . . 31 13.5. IANATn3270ResourceType . . . . . . . . . . . . . . . . . 32 13.6. IANATn3270DeviceType . . . . . . . . . . . . . . . . . . 32 13.7. IANATn3270eLogData . . . . . . . . . . . . . . . . . . . 33 14. Security Considerations . . . . . . . . . . . . . . . . . . . 34 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34 Expires August 17, 2014 [Page 3] Internet-Draft SMIv2 Textual Conventions February 2014 1. IANA-ADDRESS-FAMILY-NUMBERS-MIB (revision 2002-03-14 00:00) The MIB module defines the AddressFamilyNumbers textual convention. 1.1. AddressFamilyNumbers Expires August 17, 2014 [Page 4] Internet-Draft SMIv2 Textual Conventions February 2014 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). Expires August 17, 2014 [Page 5] Internet-Draft SMIv2 Textual Conventions February 2014 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. 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. 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 Expires August 17, 2014 [Page 6] Internet-Draft SMIv2 Textual Conventions February 2014 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. 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. Expires August 17, 2014 [Page 7] Internet-Draft SMIv2 Textual Conventions February 2014 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. Expires August 17, 2014 [Page 8] Internet-Draft SMIv2 Textual Conventions February 2014 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 4.1. FinDeviceTypeTC The defined finishing device subunit process enumerations. 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. 4.3. FinEdgeTC Specifies an edge for a Finishing Process. 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. 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 Expires August 17, 2014 [Page 9] Internet-Draft SMIv2 Textual Conventions February 2014 staple clinch will be on the inside of the resulting booklet. 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. 4.7. FinFoldingTypeTC The defined folding device process enumerations. 4.8. FinBindingTypeTC The defined binding type enumerations. 4.9. FinPunchHoleTypeTC The defined hole type punch process enumerations. 4.10. FinPunchPatternTC The defined hole pattern punch process enumerations. 4.11. FinSlittingTypeTC The defined slitting type enumerations. 4.12. FinWrappingTypeTC The defined wrapping device process enumerations. 4.13. FinStackOutputTypeTC The defined stack output type enumerations. Expires August 17, 2014 [Page 10] Internet-Draft SMIv2 Textual Conventions February 2014 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 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). 5.2. IANAGmplsSwitchingTypeTC Expires August 17, 2014 [Page 11] Internet-Draft SMIv2 Textual Conventions February 2014 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). 5.3. IANAGmplsGeneralizedPidTC Expires August 17, 2014 [Page 12] Internet-Draft SMIv2 Textual Conventions February 2014 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). 5.4. IANAGmplsAdminStatusInformationTC Expires August 17, 2014 [Page 13] Internet-Draft SMIv2 Textual Conventions February 2014 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). 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. 6.1. IANAifType Expires August 17, 2014 [Page 14] Internet-Draft SMIv2 Textual Conventions February 2014 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. 6.2. IANAtunnelType Expires August 17, 2014 [Page 15] Internet-Draft SMIv2 Textual Conventions February 2014 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. 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 7.1. IANAItuProbableCause Expires August 17, 2014 [Page 16] Internet-Draft SMIv2 Textual Conventions February 2014 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 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 Expires August 17, 2014 [Page 17] Internet-Draft SMIv2 Textual Conventions February 2014 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. 8.1. IANAscopeSource The source of multicast scope information. 8.2. IANAmallocRangeSource The source of multicast address allocation range information. 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 Expires August 17, 2014 [Page 18] Internet-Draft SMIv2 Textual Conventions February 2014 4836; for full legal notices see the RFC itself. Supplementary information may be available at: http://www.ietf.org/copyrights/ianamib.html 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. 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 Expires August 17, 2014 [Page 19] Internet-Draft SMIv2 Textual Conventions February 2014 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 Expires August 17, 2014 [Page 20] Internet-Draft SMIv2 Textual Conventions February 2014 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: Expires August 17, 2014 [Page 21] Internet-Draft SMIv2 Textual Conventions February 2014 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). 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). 9.4. IANAifJackType Expires August 17, 2014 [Page 22] Internet-Draft SMIv2 Textual Conventions February 2014 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). 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 10.1. PrtCoverStatusTC Values for encoding the state of a particular cover or access panel on the printer case or enclosure. Expires August 17, 2014 [Page 23] Internet-Draft SMIv2 Textual Conventions February 2014 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. 10.3. PrtChannelTypeTC This enumeration indicates the type of channel that is receiving jobs. 10.4. PrtInterpreterLangFamilyTC This enumeration indicates the type of interpreter that is receiving jobs. 10.5. PrtInputTypeTC The type of technology (discriminated primarily according to feeder mechanism type) employed by a specific component or components. 10.6. PrtOutputTypeTC The Type of technology supported by this output subunit. 10.7. PrtMarkerMarkTechTC The type of marking technology used for this marking subunit. 10.8. PrtMarkerSuppliesTypeTC The type of this supply. Expires August 17, 2014 [Page 24] Internet-Draft SMIv2 Textual Conventions February 2014 10.9. PrtMediaPathTypeTC The type of the media path for this media path. 10.10. PrtConsoleColorTC The color of this light. 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. 10.12. PrtAlertTrainingLevelTC Expires August 17, 2014 [Page 25] Internet-Draft SMIv2 Textual Conventions February 2014 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. 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). Expires August 17, 2014 [Page 26] Internet-Draft SMIv2 Textual Conventions February 2014 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 prtAlertTime the value of sysUpTime at Expires August 17, 2014 [Page 27] Internet-Draft SMIv2 Textual Conventions February 2014 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. 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. Expires August 17, 2014 [Page 28] Internet-Draft SMIv2 Textual Conventions February 2014 11.1. IANAPwTypeTC Indicates the PW type (i.e., the carried service). 11.2. IANAPwPsnTypeTC Identifies the PSN type that the PW will use over the network. 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. 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. 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. 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. Expires August 17, 2014 [Page 29] Internet-Draft SMIv2 Textual Conventions February 2014 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. 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. 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. 13.3. IANATn3270eClientType Expires August 17, 2014 [Page 30] Internet-Draft SMIv2 Textual Conventions February 2014 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. 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 Expires August 17, 2014 [Page 31] Internet-Draft SMIv2 Textual Conventions February 2014 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. 13.5. IANATn3270ResourceType The type of resource defined by a resource pool. Refer to tn3270eResPoolTable. 13.6. IANATn3270DeviceType This textual convention defines the list of device types that can be set, as defined by RFC 2355. Expires August 17, 2014 [Page 32] Internet-Draft SMIv2 Textual Conventions February 2014 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 Expires August 17, 2014 [Page 33] Internet-Draft SMIv2 Textual Conventions February 2014 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. 14. Security Considerations None. Author's Address Expires August 17, 2014 [Page 34]