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