diff options
Diffstat (limited to 'data/mibs/SNMP-FRAMEWORK-MIB.txt')
| -rw-r--r-- | data/mibs/SNMP-FRAMEWORK-MIB.txt | 526 |
1 files changed, 0 insertions, 526 deletions
diff --git a/data/mibs/SNMP-FRAMEWORK-MIB.txt b/data/mibs/SNMP-FRAMEWORK-MIB.txt deleted file mode 100644 index aa273c285..000000000 --- a/data/mibs/SNMP-FRAMEWORK-MIB.txt +++ /dev/null @@ -1,526 +0,0 @@ -SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN - -IMPORTS - MODULE-IDENTITY, OBJECT-TYPE, - OBJECT-IDENTITY, - snmpModules FROM SNMPv2-SMI - TEXTUAL-CONVENTION FROM SNMPv2-TC - MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; - -snmpFrameworkMIB MODULE-IDENTITY - LAST-UPDATED "200210140000Z" - ORGANIZATION "SNMPv3 Working Group" - CONTACT-INFO "WG-EMail: snmpv3@lists.tislabs.com - Subscribe: snmpv3-request@lists.tislabs.com - - Co-Chair: Russ Mundy - Network Associates Laboratories - postal: 15204 Omega Drive, Suite 300 - Rockville, MD 20850-4601 - USA - EMail: mundy@tislabs.com - phone: +1 301-947-7107 - - Co-Chair & - Co-editor: David Harrington - Enterasys Networks - postal: 35 Industrial Way - P. O. Box 5005 - Rochester, New Hampshire 03866-5005 - USA - EMail: dbh@enterasys.com - phone: +1 603-337-2614 - - Co-editor: Randy Presuhn - BMC Software, Inc. - postal: 2141 North First Street - San Jose, California 95131 - USA - EMail: randy_presuhn@bmc.com - phone: +1 408-546-1006 - - Co-editor: Bert Wijnen - Lucent Technologies - postal: Schagen 33 - 3461 GL Linschoten - Netherlands - - EMail: bwijnen@lucent.com - phone: +31 348-680-485 - " - DESCRIPTION "The SNMP Management Architecture MIB - - Copyright (C) The Internet Society (2002). This - version of this MIB module is part of RFC 3411; - see the RFC itself for full legal notices. - " - - REVISION "200210140000Z" -- 14 October 2002 - DESCRIPTION "Changes in this revision: - - Updated various administrative information. - - Corrected some typos. - - Corrected typo in description of SnmpEngineID - that led to range overlap for 127. - - Changed '255a' to '255t' in definition of - SnmpAdminString to align with current SMI. - - Reworded 'reserved' for value zero in - DESCRIPTION of SnmpSecurityModel. - - The algorithm for allocating security models - should give 256 per enterprise block, rather - than 255. - - The example engine ID of 'abcd' is not - legal. Replaced with '800002b804616263'H based - on example enterprise 696, string 'abc'. - - Added clarification that engineID should - persist across re-initializations. - This revision published as RFC 3411. - " - REVISION "199901190000Z" -- 19 January 1999 - DESCRIPTION "Updated editors' addresses, fixed typos. - Published as RFC 2571. - " - REVISION "199711200000Z" -- 20 November 1997 - DESCRIPTION "The initial version, published in RFC 2271. - " - ::= { snmpModules 10 } - - -- Textual Conventions used in the SNMP Management Architecture *** - -SnmpEngineID ::= TEXTUAL-CONVENTION - STATUS current - DESCRIPTION "An SNMP engine's administratively-unique identifier. - Objects of this type are for identification, not for - addressing, even though it is possible that an - address may have been used in the generation of - a specific value. - - The value for this object may not be all zeros or - all 'ff'H or the empty (zero length) string. - - The initial value for this object may be configured - via an operator console entry or via an algorithmic - function. In the latter case, the following - example algorithm is recommended. - - In cases where there are multiple engines on the - same system, the use of this algorithm is NOT - appropriate, as it would result in all of those - engines ending up with the same ID value. - - 1) The very first bit is used to indicate how the - rest of the data is composed. - - 0 - as defined by enterprise using former methods - that existed before SNMPv3. See item 2 below. - - 1 - as defined by this architecture, see item 3 - below. - - Note that this allows existing uses of the - engineID (also known as AgentID [RFC1910]) to - co-exist with any new uses. - - 2) The snmpEngineID has a length of 12 octets. - - The first four octets are set to the binary - equivalent of the agent's SNMP management - private enterprise number as assigned by the - Internet Assigned Numbers Authority (IANA). - For example, if Acme Networks has been assigned - { enterprises 696 }, the first four octets would - be assigned '000002b8'H. - - The remaining eight octets are determined via - one or more enterprise-specific methods. Such - methods must be designed so as to maximize the - possibility that the value of this object will - be unique in the agent's administrative domain. - For example, it may be the IP address of the SNMP - entity, or the MAC address of one of the - interfaces, with each address suitably padded - with random octets. If multiple methods are - defined, then it is recommended that the first - octet indicate the method being used and the - remaining octets be a function of the method. - - 3) The length of the octet string varies. - - The first four octets are set to the binary - equivalent of the agent's SNMP management - private enterprise number as assigned by the - Internet Assigned Numbers Authority (IANA). - For example, if Acme Networks has been assigned - { enterprises 696 }, the first four octets would - be assigned '000002b8'H. - - The very first bit is set to 1. For example, the - above value for Acme Networks now changes to be - '800002b8'H. - - The fifth octet indicates how the rest (6th and - following octets) are formatted. The values for - the fifth octet are: - - 0 - reserved, unused. - - 1 - IPv4 address (4 octets) - lowest non-special IP address - - 2 - IPv6 address (16 octets) - lowest non-special IP address - - 3 - MAC address (6 octets) - lowest IEEE MAC address, canonical - order - - 4 - Text, administratively assigned - Maximum remaining length 27 - - 5 - Octets, administratively assigned - Maximum remaining length 27 - - 6-127 - reserved, unused - - 128-255 - as defined by the enterprise - Maximum remaining length 27 - " - SYNTAX OCTET STRING (SIZE(5..32)) - -SnmpSecurityModel ::= TEXTUAL-CONVENTION - STATUS current - DESCRIPTION "An identifier that uniquely identifies a - Security Model of the Security Subsystem within - this SNMP Management Architecture. - - The values for securityModel are allocated as - follows: - - - The zero value does not identify any particular - security model. - - - Values between 1 and 255, inclusive, are reserved - for standards-track Security Models and are - managed by the Internet Assigned Numbers Authority - (IANA). - - Values greater than 255 are allocated to - enterprise-specific Security Models. An - enterprise-specific securityModel value is defined - to be: - - enterpriseID * 256 + security model within - enterprise - - For example, the fourth Security Model defined by - the enterprise whose enterpriseID is 1 would be - 259. - - This scheme for allocation of securityModel - values allows for a maximum of 255 standards- - based Security Models, and for a maximum of - 256 Security Models per enterprise. - - It is believed that the assignment of new - securityModel values will be rare in practice - because the larger the number of simultaneously - utilized Security Models, the larger the - chance that interoperability will suffer. - Consequently, it is believed that such a range - will be sufficient. In the unlikely event that - the standards committee finds this number to be - insufficient over time, an enterprise number - can be allocated to obtain an additional 256 - possible values. - - Note that the most significant bit must be zero; - hence, there are 23 bits allocated for various - organizations to design and define non-standard - - securityModels. This limits the ability to - define new proprietary implementations of Security - Models to the first 8,388,608 enterprises. - - It is worthwhile to note that, in its encoded - form, the securityModel value will normally - require only a single byte since, in practice, - the leftmost bits will be zero for most messages - and sign extension is suppressed by the encoding - rules. - - As of this writing, there are several values - of securityModel defined for use with SNMP or - reserved for use with supporting MIB objects. - They are as follows: - - 0 reserved for 'any' - 1 reserved for SNMPv1 - 2 reserved for SNMPv2c - 3 User-Based Security Model (USM) - " - SYNTAX INTEGER(0 .. 2147483647) - -SnmpMessageProcessingModel ::= TEXTUAL-CONVENTION - STATUS current - DESCRIPTION "An identifier that uniquely identifies a Message - Processing Model of the Message Processing - Subsystem within this SNMP Management Architecture. - - The values for messageProcessingModel are - allocated as follows: - - - Values between 0 and 255, inclusive, are - reserved for standards-track Message Processing - Models and are managed by the Internet Assigned - Numbers Authority (IANA). - - - Values greater than 255 are allocated to - enterprise-specific Message Processing Models. - An enterprise messageProcessingModel value is - defined to be: - - enterpriseID * 256 + - messageProcessingModel within enterprise - - For example, the fourth Message Processing Model - defined by the enterprise whose enterpriseID - - is 1 would be 259. - - This scheme for allocating messageProcessingModel - values allows for a maximum of 255 standards- - based Message Processing Models, and for a - maximum of 256 Message Processing Models per - enterprise. - - It is believed that the assignment of new - messageProcessingModel values will be rare - in practice because the larger the number of - simultaneously utilized Message Processing Models, - the larger the chance that interoperability - will suffer. It is believed that such a range - will be sufficient. In the unlikely event that - the standards committee finds this number to be - insufficient over time, an enterprise number - can be allocated to obtain an additional 256 - possible values. - - Note that the most significant bit must be zero; - hence, there are 23 bits allocated for various - organizations to design and define non-standard - messageProcessingModels. This limits the ability - to define new proprietary implementations of - Message Processing Models to the first 8,388,608 - enterprises. - - It is worthwhile to note that, in its encoded - form, the messageProcessingModel value will - normally require only a single byte since, in - practice, the leftmost bits will be zero for - most messages and sign extension is suppressed - by the encoding rules. - - As of this writing, there are several values of - messageProcessingModel defined for use with SNMP. - They are as follows: - - 0 reserved for SNMPv1 - 1 reserved for SNMPv2c - 2 reserved for SNMPv2u and SNMPv2* - 3 reserved for SNMPv3 - " - SYNTAX INTEGER(0 .. 2147483647) - -SnmpSecurityLevel ::= TEXTUAL-CONVENTION - STATUS current - DESCRIPTION "A Level of Security at which SNMP messages can be - sent or with which operations are being processed; - in particular, one of: - - noAuthNoPriv - without authentication and - without privacy, - authNoPriv - with authentication but - without privacy, - authPriv - with authentication and - with privacy. - - These three values are ordered such that - noAuthNoPriv is less than authNoPriv and - authNoPriv is less than authPriv. - " - SYNTAX INTEGER { noAuthNoPriv(1), - authNoPriv(2), - authPriv(3) - } - -SnmpAdminString ::= TEXTUAL-CONVENTION - DISPLAY-HINT "255t" - STATUS current - DESCRIPTION "An octet string containing administrative - information, preferably in human-readable form. - - To facilitate internationalization, this - information is represented using the ISO/IEC - IS 10646-1 character set, encoded as an octet - string using the UTF-8 transformation format - described in [RFC2279]. - - Since additional code points are added by - amendments to the 10646 standard from time - to time, implementations must be prepared to - encounter any code point from 0x00000000 to - 0x7fffffff. Byte sequences that do not - correspond to the valid UTF-8 encoding of a - code point or are outside this range are - prohibited. - - The use of control codes should be avoided. - - When it is necessary to represent a newline, - the control code sequence CR LF should be used. - - The use of leading or trailing white space should - be avoided. - - For code points not directly supported by user - interface hardware or software, an alternative - means of entry and display, such as hexadecimal, - may be provided. - - For information encoded in 7-bit US-ASCII, - the UTF-8 encoding is identical to the - US-ASCII encoding. - - UTF-8 may require multiple bytes to represent a - single character / code point; thus the length - of this object in octets may be different from - the number of characters encoded. Similarly, - size constraints refer to the number of encoded - octets, not the number of characters represented - by an encoding. - - Note that when this TC is used for an object that - is used or envisioned to be used as an index, then - a SIZE restriction MUST be specified so that the - number of sub-identifiers for any object instance - does not exceed the limit of 128, as defined by - [RFC3416]. - - Note that the size of an SnmpAdminString object is - measured in octets, not characters. - " - SYNTAX OCTET STRING (SIZE (0..255)) - --- Administrative assignments *************************************** - -snmpFrameworkAdmin - OBJECT IDENTIFIER ::= { snmpFrameworkMIB 1 } -snmpFrameworkMIBObjects - OBJECT IDENTIFIER ::= { snmpFrameworkMIB 2 } -snmpFrameworkMIBConformance - OBJECT IDENTIFIER ::= { snmpFrameworkMIB 3 } - --- the snmpEngine Group ******************************************** - -snmpEngine OBJECT IDENTIFIER ::= { snmpFrameworkMIBObjects 1 } - -snmpEngineID OBJECT-TYPE - SYNTAX SnmpEngineID - MAX-ACCESS read-only - STATUS current - DESCRIPTION "An SNMP engine's administratively-unique identifier. - - This information SHOULD be stored in non-volatile - storage so that it remains constant across - re-initializations of the SNMP engine. - " - ::= { snmpEngine 1 } - -snmpEngineBoots OBJECT-TYPE - SYNTAX INTEGER (1..2147483647) - MAX-ACCESS read-only - STATUS current - DESCRIPTION "The number of times that the SNMP engine has - (re-)initialized itself since snmpEngineID - was last configured. - " - ::= { snmpEngine 2 } - -snmpEngineTime OBJECT-TYPE - SYNTAX INTEGER (0..2147483647) - UNITS "seconds" - MAX-ACCESS read-only - STATUS current - DESCRIPTION "The number of seconds since the value of - the snmpEngineBoots object last changed. - When incrementing this object's value would - cause it to exceed its maximum, - snmpEngineBoots is incremented as if a - re-initialization had occurred, and this - object's value consequently reverts to zero. - " - ::= { snmpEngine 3 } - -snmpEngineMaxMessageSize OBJECT-TYPE - SYNTAX INTEGER (484..2147483647) - MAX-ACCESS read-only - STATUS current - DESCRIPTION "The maximum length in octets of an SNMP message - which this SNMP engine can send or receive and - process, determined as the minimum of the maximum - message size values supported among all of the - transports available to and supported by the engine. - " - ::= { snmpEngine 4 } - --- Registration Points for Authentication and Privacy Protocols ** - -snmpAuthProtocols OBJECT-IDENTITY - STATUS current - DESCRIPTION "Registration point for standards-track - authentication protocols used in SNMP Management - Frameworks. - " - ::= { snmpFrameworkAdmin 1 } - -snmpPrivProtocols OBJECT-IDENTITY - STATUS current - DESCRIPTION "Registration point for standards-track privacy - protocols used in SNMP Management Frameworks. - " - ::= { snmpFrameworkAdmin 2 } - --- Conformance information ****************************************** - -snmpFrameworkMIBCompliances - OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 1} -snmpFrameworkMIBGroups - OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 2} - --- compliance statements - -snmpFrameworkMIBCompliance MODULE-COMPLIANCE - STATUS current - DESCRIPTION "The compliance statement for SNMP engines which - implement the SNMP Management Framework MIB. - " - MODULE -- this module - MANDATORY-GROUPS { snmpEngineGroup } - ::= { snmpFrameworkMIBCompliances 1 } - --- units of conformance - -snmpEngineGroup OBJECT-GROUP - OBJECTS { - snmpEngineID, - snmpEngineBoots, - snmpEngineTime, - snmpEngineMaxMessageSize - } - STATUS current - DESCRIPTION "A collection of objects for identifying and - determining the configuration and current timeliness - - values of an SNMP engine. - " - ::= { snmpFrameworkMIBGroups 1 } - -END |