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