+++ /dev/null
-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
projects / bcm963xx.git / blobdiff