for authors and reviewers of documents that define MIB modules to
ensure that those documents fully comply with the guidelines in
http://www.ops.ietf.org/mib-security.html so that all such risks are
adequately disclosed.
7. IANA Considerations
This document affects the IANA to the extent that it describes what
is required to be present in the IANA Considerations section of a MIB
document, but it does not require that the IANA update any existing
registry or create any new registry.
Appendix A: MIB Review Checklist
The purpose of a MIB review is to review the MIB module both for
technical correctness and for adherence to IETF documentation
requirements. The following checklist may be helpful when reviewing
a draft document:
1.) I-D Boilerplate -- verify that the draft contains the required
Internet-Draft boilerplate (see http://www.ietf.org/ietf/1id-
guidelines.txt), including the appropriate statement to permit
publication as an RFC, and that I-D boilerplate does not contain
references or section numbers.
2.) Abstract -- verify that the abstract does not contain references,
that it does not have a section number, and that its content follows
the guidelines in http://www.ietf.org/ietf/1id-guidelines.txt.
3.) MIB Boilerplate -- verify that the draft contains the latest
approved SNMP Network Management Framework boilerplate from the OPS
area web site (http://www.ops.ietf.org/mib-boilerplate.html).
4.) Security Considerations Section -- verify that the draft uses the
latest approved template from the OPS area web site
(http://www.ops.ietf.org/mib-security.html) and that the guidelines
therein have been followed.
5.) IANA Considerations Section -- this section must always be
present. If the draft requires no action from the IANA, ensure that
this is explicitly noted. If the draft requires OID values to be
assigned, ensure that the IANA Considerations section contains the
information specified in Section 3.5 of these guidelines. If the
draft contains the initial version of an IANA-maintained module,
verify that the MODULE-IDENTITY invocation contains maintenance
instructions that comply with the requirements in RFC 2434. In the
latter case, the IANA Considerations section that will appear in the
RFC MUST contain a pointer to the actual IANA-maintained module.
6.) References -- verify that the references are properly divided
between normative and informative references, that RFC 2119 is
included as a normative reference if the terminology defined therein
is used in the document, that all references required by the
boilerplate are present, that all MIB modules containing imported
items are cited as normative references, and that all citations point
to the most current RFCs unless there is a valid reason to do
otherwise (for example, it is OK to include an informative reference
to a previous version of a specification to help explain a feature
included for backward compatibility).
7.) Copyright Notices -- verify that the draft contains an
abbreviated copyright notice in the DESCRIPTION clause of each
MODULE-IDENTITY invocation and that it contains the full copyright
notice and disclaimer specified in Sections 5.4 and 5.5 of RFC 3978
at the end of the document. Make sure that the correct year is used
in all copyright dates.
8.) IPR Notice -- if the draft does not contains a verbatim copy of
the IPR notice specified in Section 5 of RFC 3979, recommend that the
IPR notice be included.
9.) Other Issues -- check for any issues mentioned in
http://www.ietf.org/ID-Checklist.html that are not covered elsewhere.
10.) Technical Content -- review the actual technical content for
compliance with the guidelines in this document. The use of a MIB
compiler is recommended when checking for syntax errors; see
http://www.ops.ietf.org/mib-review-tools.html for more information.
Checking for correct syntax, however, is only part of the job. It is
just as important to actually read the MIB document from the point of
view of a potential implementor. It is particularly important to
check that DESCRIPTION clauses are sufficiently clear and unambiguous
to allow interoperable implementations to be created.
Appendix B: Commonly Used Textual Conventions
The following TCs are defined in SNMPv2-TC [RFC2579]:
DisplayString OCTET STRING (SIZE (0..255))
PhysAddress OCTET STRING
MacAddress OCTET STRING (SIZE (6))
TruthValue enumerated INTEGER
TestAndIncr INTEGER (0..2147483647)
AutonomousType OBJECT IDENTIFIER
VariablePointer OBJECT IDENTIFIER
RowPointer OBJECT IDENTIFIER
RowStatus enumerated INTEGER
TimeStamp TimeTicks
TimeInterval INTEGER (0..2147483647)
DateAndTime OCTET STRING (SIZE (8 | 11))
StorageType enumerated INTEGER
TDomain OBJECT IDENTIFIER
TAddress OCTET STRING (SIZE (1..255))
Note 1. InstancePointer is obsolete and MUST NOT be used.
Note 2. DisplayString does not support internationalized text. It
MUST NOT be used for objects that are required to hold
internationalized text (which is always the case if the
object is intended for use by humans [RFC2277]). Designers
SHOULD consider using SnmpAdminString, Utf8String, or
LongUtf8String for such objects.
Note 3. TDomain and TAddress SHOULD NOT be used in new MIB modules.
The TransportDomain, TransportAddressType, and
TransportAddress TCs (defined in TRANSPORT-ADDRESS-MIB
[RFC3419]) SHOULD be used instead.
The following TC is defined in SNMP-FRAMEWORK-MIB [RFC3411]:
SnmpAdminString OCTET STRING (SIZE (0..255))
The following TCs are defined in SYSAPPL-MIB [RFC2287]:
Utf8String OCTET STRING (SIZE (0..255))
LongUtf8String OCTET STRING (SIZE (0..1024))
The following TCs are defined in INET-ADDRESS-MIB [RFC4001]:
InetAddressType enumerated INTEGER
InetAddress OCTET STRING (SIZE (0..255))
InetAddressPrefixLength Unsigned32 (0..2040)
InetPortNumber Unsigned32 (0..65535))
InetAutonomousSystemNumber Unsigned32
InetScopeType enumerated INTEGER
InetZoneIndex Unsigned32
InetVersion enumerated INTEGER
The following TCs are defined in TRANSPORT-ADDRESS-MIB [RFC3419]:
TransportDomain OBJECT IDENTIFIER
TransportAddressType enumerated INTEGER
TransportAddress OCTET STRING (SIZE (0..255))
The following TC is defined in RMON2-MIB [RFC2021]:
ZeroBasedCounter32 Gauge32
The following TCs are defined in HCNUM-TC [RFC2856]:
ZeroBasedCounter64 Counter64
CounterBasedGauge64 Counter64
The following TCs are defined in IF-MIB [RFC2863]:
InterfaceIndex Integer32 (1..2147483647)
InterfaceIndexOrZero Integer32 (0..2147483647)
The following TCs are defined in ENTITY-MIB [RFC4133]:
PhysicalIndex Integer32 (1..2147483647)
PhysicalIndexOrZero Integer32 (0..2147483647)
The following TCs are defined in PerfHist-TC-MIB [RFC3593]:
PerfCurrentCount Gauge32
PerfIntervalCount Gauge32
PerfTotalCount Gauge32
The following TCs are defined in HC-PerfHist-TC-MIB [RFC3705]:
HCPerfValidIntervals Integer32 (0..96)
HCPerfInvalidIntervals Integer32 (0..96)
HCPerfTimeElapsed Integer32 (0..86399)
HCPerfIntervalThreshold Unsigned32 (0..900)
HCPerfCurrentCount Counter64
HCPerfIntervalCount Counter64
HCPerfTotalCount Counter64
Appendix C: Suggested Naming Conventions
Authors and reviewers of IETF MIB modules have often found the
following naming conventions to be helpful in the past, and authors
of new IETF MIB modules are urged to consider following them.
- The module name should be of the form XXX-MIB (or XXX-TC-MIB for a
module with TCs only), where XXX is a unique prefix (usually all
caps with hyphens for separators) that is not used by any existing
module. For example, the module for managing optical interfaces
[RFC3591] uses the prefix OPT-IF and has module name OPT-IF-MIB.
- The descriptor associated with the MODULE-IDENTITY invocation
should be of the form xxxMIB, xxxMib, or xxxMibModule, where xxx is
a mixed-case version of XXX starting with a lowercase letter and
without any hyphens. For example, the OPT-IF-MIB uses the prefix
optIf, and the descriptor associated with its MODULE-IDENTITY
invocation is optIfMibModule.
- Other descriptors within the MIB module should start with the same
prefix xxx. OPT-IF-MIB uses the prefix optIf for all descriptors.
- Names of TCs that are specific to the MIB module and names of
SEQUENCE types that are used in conceptual table definitions should
start with a prefix Xxx that is the same as xxx but with the
initial letter changed to uppercase. OPT-IF-MIB uses the prefix
OptIf on the names of TCs and SEQUENCE types.
- The descriptor associated with a conceptual table should be of the
form xxxZzzTable; the descriptor associated with the corresponding
conceptual row should be of the form xxxZzzEntry; the name of the
associated SEQUENCE type should be of the form XxxZzzEntry; and the
descriptors associated with the subordinate columnar objects should
be of the form xxxZzzSomeotherName. An example from the OPT-IF-MIB
is the OTMn table. The descriptor of the table object is
optIfOTMnTable, the descriptor of the row object is optIfOTMnEntry,
the name of the associated SEQUENCE type is OptIfOTMnEntry, and the
descriptors of the columnar objects are optIfOTMnOrder,
optIfOTMnReduced, optIfOTMnBitRates, optIfOTMnInterfaceType,
optIfOTMnTcmMax, and optIfOTMnOpticalReach.
- When abbreviations are used, then they should be used consistently.
Inconsistent usage such as
xxxYyyDestAddr
xxxZzzDstAddr
should be avoided.
Appendix D: Suggested OID Layout
As noted in RFC 2578 Section 5.6, it is common practice to use the
value of the MODULE-IDENTITY invocation as a subtree under which
other OBJECT IDENTIFIER values assigned within the module are
defined. That, of course, leaves open the question of how OIDs are
assigned within that subtree. One assignment scheme that has gained
favor -- and that is RECOMMENDED unless there is a specific reason
not use it -- is to have three separate branches immediately below
the MODULE-IDENTITY value dedicated (respectively) to notification
definitions, object definitions, and conformance definitions, and to
further subdivide the conformance branch into separate sub-branches
for compliance statements and object/notification groups. This
structure is illustrated below, with naming conventions following
those outlined in Appendix C. The numbers in parentheses are the
sub-identifiers assigned to the branches.
xxxMIB
|
+-- xxxNotifications(0)
+-- xxxObjects(1)
+-- xxxConformance(2)
|
+-- xxxCompliances(1)
+-- xxxGroups(2)
When using this scheme, notification definition values are assigned
immediately below the xxxNotifications node. This ensures that each
OID assigned to a notification definition has a next-to-last sub-
identifier of zero, which is REQUIRED by Section 4.7 above. The
other sub-branches may have additional sub-structure, but none beyond
that specified in Section 4.6.5 above is actually required.
One example of a MIB module whose OID assignments follow this scheme
is the POWER-ETHERNET-MIB [RFC3621].
Normative References
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
J., Rose, M., and S. Waldbusser, "Structure of
Management Information Version 2 (SMIv2)", STD 58, RFC
2578, April 1999.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
J., Rose, M., and S. Waldbusser, "Textual Conventions
for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
J., Rose, M., and S. Waldbusser, "Conformance Statements
for SMIv2", STD 58, RFC 2580, April 1999.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirements Levels", BCP 14, RFC 2119, March 1997.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC2864] McCloghrie, K. and G. Hanson, "The Inverted Stack Table
Extension to the Interfaces Group MIB", RFC 2864, June
2000.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
3978, March 2005.
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005.
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder, "Textual Conventions for Internet Network
Addresses", RFC 4001, February 2005.
[RFC3593] Tesink, K., "Textual Conventions for MIB Modules Using
Performance History Based on 15 Minute Intervals", RFC
3593, September 2003.
[RFC3705] Ray, B. and R. Abbi, "High Capacity Textual Conventions
for MIB Modules Using Performance History Based on 15
Minute Intervals", RFC 3705, February 2004.
[RFC2021] Waldbusser, S., "Remote Network Monitoring Management
Information Base Version 2 using SMIv2", RFC 2021,
January 1997.
[RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual
Conventions for Additional High Capacity Data Types",
RFC 2856, June 2000.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC
3411, December 2002.
[RFC2287] Krupczak, C. and J. Saperia, "Definitions of
System-Level Managed Objects for Applications", RFC
2287, February 1998.
[RFC3418] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Management Information Base (MIB) for the
Simple Network Management Protocol (SNMP)", STD 62, RFC
3418, December 2002.
[RFC3416] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Protocol Operations for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3416, December
2002.
[RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)",
RFC 4133, August 2005.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[RFC3419] Daniele, M. and J. Schoenwaelder, "Textual Conventions
for Transport Addresses", RFC 3419, December 2002.
Informative References
[RFC1155] Rose, M. and K. McCloghrie, "Structure and
Identification of Management Information for
TCP/IP-based Internets", STD 16, RFC 1155, May 1990.
[RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions",
STD 16, RFC 1212, March 1991.
[RFC1215] Rose, M., "A Convention for Defining Traps for use with
the SNMP", RFC 1215, March 1991.
[RFC2223bis] Reynolds, J. and R. Braden, "Instructions to Request for
Comments (RFC) Authors", Work in Progress, August 2004.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for
Internet-Standard Management Framework", RFC 3410,
December 2002.
[RFC2932] McCloghrie, K., Farinacci, D., and D. Thaler, "IPv4
Multicast Routing MIB", RFC 2932, October 2000.
[RFC1573] McCloghrie, K. and F. Kastenholz, "Evolution of the
Interfaces Group of MIB-II", RFC 1573, January 1994.
[RFC3621] Berger, A. and D. Romascanu, "Power Ethernet MIB", RFC
3621, December 2003.
[RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen,
"Coexistence between Version 1, Version 2, and Version 3
of the Internet-standard Network Management Framework",
BCP 74, RFC 3584, August 2003.
[RFC2108] de Graaf, K., Romascanu, D., McMaster, D., and K.
McCloghrie, "Definitions of Managed Objects for IEEE
802.3 Repeater Devices using SMIv2", RFC 2108, February
1997.
[RFC3289] Baker, F., Chan, K., and A. Smith, "Management
Information Base for the Differentiated Services
Architecture", RFC 3289, May 2002.
[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base
for Network Management of TCP/IP-based internets - MIB-
II", STD 17, RFC 1213, March 1991.
[RFC1595] Brown, T. and K. Tesink, "Definitions of Managed Objects
for the SONET/SDH Interface Type", RFC 1595, March 1994.
[RFC2558] Tesink, K., "Definitions of Managed Objects for the
SONET/SDH Interface Type", RFC 2558, March 1999.
[RFC3591] Lam, H-K., Stewart, M., and A. Huynh, "Definitions of
Managed Objects for the Optical Interface Type", RFC
3591, September 2003.
Editor’s Address
C. M. Heard
158 South Madison Ave. #207
Pasadena, CA 91101-2569
USA
Phone: +1 626 795 5311
EMail: heard@pobox.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.