RFC 4181
Guidelines for Authors and Reviewers of MIB Documents
RFC 4181: Guidelines for Authors and Reviewers of MIB Documents 🎀
Okay bestie, so this is RFC 4181 🦋 It's a Best Current Practice, filed as BCP 111 with the category Best Current Practice. It came out in September 2005 from the Network Working Group, and the author is C. Heard, Ed. 💖 Its whole job is to give authors and reviewers of MIB documents a set of guidelines. Its header doesn't list any Obsoletes or Updates entries, so it isn't replacing or changing another RFC on that front 💅
Network Working Group C. Heard, Ed.
Request for Comments: 4181 September 2005
BCP: 111
Category: Best Current PracticeStatus of This Memo ✨
This document is a BCP for the Internet Community, and it's asking for discussion and suggestions for improvements 🫶 Distribution of this memo is unlimited, so share it with your whole group chat 💜
Copyright Notice 🌸
Copyright (C) The Internet Society (2005).
Abstract 🦋
So the gist is that this memo gives guidelines for authors and reviewers of IETF standards-track specifications that contain MIB modules 🔥 Parts of it can also be used as a basis for reviewing other MIB documents, which is giving versatile 💅
Table of Contents 📖
1. Introduction ....................................................3
2. Terminology .....................................................3
3. General Documentation Guidelines ................................4
3.1. MIB Boilerplate Section ....................................4
3.2. Narrative Sections .........................................5
3.3. Definitions Section ........................................5
3.4. Security Considerations Section ............................5
3.5. IANA Considerations Section ................................6
3.5.1. Documents that Create a New Name Space ..............6
3.5.2. Documents that Require Assignments in
Existing Namespace(s) ...............................7
3.5.3. Documents with No IANA Requests .....................8
3.6. References Sections ........................................8
3.7. Copyright Notices ..........................................9
3.8. Intellectual Property Section .............................10
4. SMIv2 Usage Guidelines .........................................10
4.1. Module Names ..............................................10
4.2. Descriptors, TC Names, and Labels .........................10
4.3. Naming Hierarchy ..........................................11
4.4. IMPORTS Statement .........................................11
4.5. MODULE-IDENTITY Invocation ................................12
4.6. Textual Conventions and Object Definitions ................14
4.6.1. Usage of Data Types ................................14
4.6.1.1. INTEGER, Integer32, Gauge32, and
Unsigned32 ................................14
4.6.1.2. Counter32 and Counter64 ...................16
4.6.1.3. CounterBasedGauge64 .......................17
4.6.1.4. OCTET STRING ..............................17
4.6.1.5. OBJECT IDENTIFIER .........................18
4.6.1.6. The BITS Construct ........................19
4.6.1.7. IpAddress .................................19
4.6.1.8. TimeTicks .................................19
4.6.1.9. TruthValue ................................19
4.6.1.10. Other Data Types .........................19
4.6.2. DESCRIPTION and REFERENCE Clauses ..................20
4.6.3. DISPLAY-HINT Clause ................................21
4.6.4. Conceptual Table Definitions .......................21
4.6.5. OID Values Assigned to Objects .....................23
4.6.6. OID Length Limitations and Table Indexing ..........24
4.7. Notification Definitions ..................................24
4.8. Compliance Statements .....................................25
4.8.1. Note Regarding These Examples and RFC 2578 .........27
4.9. Revisions to MIB Modules ..................................28
5. Acknowledgments ................................................31
6. Security Considerations ........................................32
7. IANA Considerations ............................................32
Appendix A: MIB Review Checklist .................................33
Appendix B: Commonly Used Textual Conventions ....................34
Appendix C: Suggested Naming Conventions .........................36
Appendix D: Suggested OID Layout .................................37
Normative References ..............................................38
Informative References ............................................401. Introduction 🌈
Some time ago the IESG set up a policy requiring expert review of IETF standards-track specifications that contain MIB modules 👑 These reviews exist so that the specs follow established IETF documentation practices, and so that the MIB modules inside meet certain generally accepted standards of quality. That includes (but isn't limited to) compliance with all syntactic and semantic requirements of SMIv2 (STD 58) [RFC2578] [RFC2579] [RFC2580] that apply to "standard" MIB modules 🧚 This memo exists to write down the guidelines those reviews follow.
Now, please note that the guidelines here are not meant to change requirements or prohibitions (in the sense of "MUST", "MUST NOT", "SHALL", or "SHALL NOT" as defined in RFC 2119 [RFC2119]) of existing BCPs or Internet Standards. The one exception is where those requirements or prohibitions are ambiguous or contradictory 🙈 In those rare cases, this memo writes down the current generally accepted interpretation. In some situations the guidelines here DO change recommendations (in the sense of "SHOULD", "SHOULD NOT", "RECOMMENDED", or "NOT RECOMMENDED" as defined in RFC 2119) of existing BCPs or Internet Standards. That's been done where real-world experience showed that the published recommendations weren't the best they could be ✨ On top of that, this memo gives guidance on picking certain SMIv2 options (in the sense of "MAY" or "OPTIONAL" as defined in RFC 2119) in cases where there's consensus on a preferred approach 💖
Some of these guidelines don't apply to non-standards track or non-IETF MIB documents. Even so, authors and reviewers of those docs should consider using the ones that do apply 🫶
Reviewers and authors also need to know that some of the guidelines here don't apply to MIB modules that were translated to SMIv2 from SMIv1 (STD 16) [RFC1155] [RFC1212] [RFC1215] 🍓
2. Terminology 💅
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL", when used in the guidelines in this memo, are to be interpreted as described in RFC 2119 [RFC2119] 🔥
"MIB module" and "information module" are used interchangeably in this memo. Both terms mean any of the three types of information modules defined in Section 3 of RFC 2578 [RFC2578] 🦋
The term "standard", when it appears in quotes, means the same thing as in the SMIv2 documents [RFC2578] [RFC2579] [RFC2580]. Specifically, it points to the requirements those documents put on "standard" modules or "standard" objects 💜
3. General Documentation Guidelines 📖
Generally speaking, IETF standards-track specifications containing MIB modules have to meet the same requirements as IETF standards-track RFCs (see [RFC2223bis]), though there are a few differences 👑 The big one: since the version under review will be an Internet-Draft, the notices on the front page MUST comply with the requirements of http://www.ietf.org/ietf/1id-guidelines.txt and not with those of [RFC2223bis]. Also, since the spec under review is expected to be submitted to the IESG, it MUST comply with certain requirements that don't necessarily apply to RFCs. Check http://www.ietf.org/ID-Checklist.html for the details 🫶
Section 4 of [RFC2223bis] lists the sections that may exist in an RFC. Sections from the abstract onward may also be present in an Internet-Draft; see http://www.ietf.org/ID-Checklist.html 🌸 The "body of memo" is always required, and in a MIB document it MUST contain at least the following:
- MIB boilerplate section
- Narrative sections
- Definitions section
- Security Considerations section
- IANA Considerations section
- References section
Section-by-section guidelines come next 💖
3.1. MIB Boilerplate Section ✨
This section MUST contain a verbatim copy of the latest approved Internet-Standard Management Framework boilerplate, which is available online at http://www.ops.ietf.org/mib-boilerplate.html 🎀
3.2. Narrative Sections 🦋
The narrative part MUST include an overview section. That section describes the scope and field of application of the MIB modules the spec defines, and it says how those MIB modules relate (if at all) to other standards, especially standards that contain other MIB modules 🌈 The narrative part SHOULD include one or more sections that briefly describe the structure of the MIB modules defined in the spec 🧚
If the MIB modules defined by the spec import definitions from other MIB modules (except the ones defined in the SMIv2 documents [RFC2578] [RFC2579] [RFC2580]), or if they're always implemented alongside other MIB modules, then those facts MUST be noted in the overview section. Any special interpretations of objects in other MIB modules MUST be noted there too 💅 For instance, so-called media-specific MIB modules are always implemented in conjunction with the IF-MIB [RFC2863], and they are REQUIRED to document how certain objects in the IF-MIB are used 👑 Also, media-specific MIB modules that rely on the ifStackTable [RFC2863] and the ifInvStackTable [RFC2864] to keep track of configuration and multiplexing of interface sublayers MUST contain a description of the layering model 🔥
3.3. Definitions Section 💜
This section contains the MIB module(s) the spec defines. These MIB modules MUST be written in SMIv2 [RFC2578] [RFC2579] [RFC2580]. SMIv1 [RFC1155] [RFC1212] [RFC1215] has "Not Recommended" status [RFC3410] and is no longer acceptable in IETF MIB modules 🙈
See Section 4 for guidelines on SMIv2 usage 🍓
3.4. Security Considerations Section 🚨
Okay, this one is SERIOUS, so pay attention 😭 Every spec that defines one or more MIB modules MUST contain a section discussing the security considerations relevant to those modules. That section MUST be patterned after the latest approved template, available at http://www.ops.ietf.org/mib-security.html 💀
Here's the core of it. Writable MIB objects that could be especially disruptive if abused MUST be explicitly listed by name, and the associated security risks MUST be spelled out. Likewise, readable MIB objects that contain especially sensitive information, or that raise significant privacy concerns, MUST be explicitly listed by name, and the reasons for the sensitivity or privacy concerns MUST be explained 🔥 If there are no risks or vulnerabilities for a specific category of MIB objects, that fact MUST be explicitly stated 🫶
Not mentioning a category of MIB objects does NOT count as saying there are no risks or vulnerabilities in that category. It gets treated as an act of omission, and the document gets sent back to the author for correction 😭
And remember, the goal isn't to blindly copy text from the template 💅 The goal is to actually think through the risks and vulnerabilities, then write down what you found 🦋
3.5. IANA Considerations Section ✨
okay bestie, this is the IANA section 🎀 so, to follow IESG policy (you can check it at http://www.ietf.org/ID-Checklist.html), every Internet-Draft that gets submitted to the IESG for publication MUST contain an IANA Considerations section. 💅 What that section needs to say depends on what the IANA actually has to do.
3.5.1. Documents that Create a New Name Space 🌸
If an Internet-Draft defines a new name space that the IANA is going to administer, then the document MUST include an IANA Considerations section conforming to the guidelines set forth in RFC 2434 [RFC2434] that specifies how the name space is to be administered.
Name spaces defined by MIB documents usually look like one of two things: a range of values for some type (usually an enumerated INTEGER) defined by a TEXTUAL-CONVENTION (TC), or a set of administratively-defined OBJECT IDENTIFIER (OID) values. 🦋 Either way, the definitions live in stand-alone MIB modules that the IANA maintains. These IANA-maintained modules are kept separate from the MIB modules in standards-track specifications, so new assignments can happen without republishing a standards-track RFC (iconic, right?). Examples include the IANAifType-MIB (http://www.iana.org/assignments/ianaiftype-mib), which defines a name space used by the IF-MIB [RFC2863], and the IANA-RTPROTO-MIB (http://www.iana.org/assignments/ianaiprouteprotocol-mib), which defines a name space used by the IPMROUTE-STD-MIB [RFC2932].
The current practice here is to put a detailed IANA Considerations section complying with RFC 2434 into the DESCRIPTION clause of the MODULE-IDENTITY invocation in each IANA-maintained MIB module. The IANA Considerations section of the MIB document that defines the name spaces should then point to the URLs for those modules. See RFC 2932 [RFC2932] for an example. 🧚 Now here's the chicken-and-egg problem 🙈: for MIB documents that haven't been published as RFCs yet, the IANA-maintained modules won't exist yet. The accepted way out is to include the initial content of each IANA-maintained MIB module in a non-normative section of the initial issue of the document that defines the name space. For an example, see [RFC1573], which documents the initial version of the IANAifType-MIB. That material is usually left out of later updates to the document, since the IANA-maintained modules are available online by then (cf. [RFC2863]).
Reviewers of draft MIB documents that these considerations apply to MUST check that the IANA Considerations section proposed for publication in the RFC is present and contains pointers to the appropriate IANA-maintained MIB modules. Reviewers of Internet-Drafts that contain the proposed initial content of IANA-maintained MIB modules MUST also verify that the DESCRIPTION clauses of the MODULE-IDENTITY invocations contain an IANA Considerations section compliant with the guidelines in RFC 2434.
3.5.2. Documents that Require Assignments in Existing Namespace(s) 🍓
If an Internet-Draft requires the IANA to update an existing registry before it's published as an RFC, then the IANA Considerations section in the draft MUST document that fact. MIB documents that contain the initial version of a MIB module will usually need the IANA to assign an OBJECT IDENTIFIER value for the MIB module's MODULE-IDENTITY value, and possibly to make other assignments too. Internet-Drafts containing such MIB modules MUST contain an IANA Considerations section that specifies the registries to be updated, the descriptors that OBJECT IDENTIFIER values are being assigned to, and the subtrees under which the values are to be allocated. The text SHOULD be written so that, after publication, it will serve to document the OBJECT IDENTIFIER assignments.
For example, something like the following would be appropriate for an Internet-Draft containing a single MIB module with MODULE-IDENTITY descriptor powerEthernetMIB that is to be assigned a value under the 'mib-2' subtree:
The MIB module in this document uses the following IANA-assigned
OBJECT IDENTIFIER values recorded in the SMI Numbers registry:
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
powerEthernetMIB { mib-2 XXX }
Editor's Note (to be removed prior to publication): the IANA is
requested to assign a value for "XXX" under the 'mib-2' subtree
and to record the assignment in the SMI Numbers registry. When
the assignment has been made, the RFC Editor is asked to replace
"XXX" (here and in the MIB module) with the assigned value and to
remove this note.Note well: prior to official assignment by the IANA, a draft document MUST use placeholders (such as "XXX" above) rather than actual numbers. See Section 4.5 for an example of how this is done in a draft MIB module.
3.5.3. Documents with No IANA Requests 🌈
If an Internet-Draft makes no requests of the IANA, then that fact MUST be documented in the IANA Considerations section. When an Internet-Draft contains an update of a previously published MIB module, it typically won't need any action from the IANA. It may, however, inherit an IANA Considerations section documenting existing assignments from the RFC that contains the previous version of the MIB module. In those cases, the draft MUST contain a note (to be removed prior to publication) that explicitly says nothing is required from the IANA. For example, a draft with an updated version of the POWER-ETHERNET-MIB [RFC3621] might include an IANA Considerations section like this:
The MIB module in this document uses the following IANA-assigned
OBJECT IDENTIFIER values recorded in the SMI Numbers registry:
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
powerEthernetMIB { mib-2 105 }
Editor's Note (to be removed prior to publication): this draft
makes no additional requests of the IANA.If an Internet-Draft makes no requests of the IANA and there are no existing assignments to document, then suitable text for the draft would be something like the following:
No IANA actions are required by this document.3.6. References Sections 📚
Section 4.7f of [RFC2223bis] specifies the requirements for the references sections in an RFC, and http://www.ietf.org/ID-Checklist.html imposes the same requirements on Internet-Drafts. In particular, there MUST be separate lists of normative and informative references, each in a separate section. The style SHOULD follow that of recently published RFCs.
The standard MIB boilerplate, available at http://www.ops.ietf.org/mib-boilerplate.html, includes lists of normative and informative references that MUST appear in all IETF specifications that contain MIB modules. If items from other MIB modules appear in an IMPORTS statement in the Definitions section, then the specifications containing those MIB modules MUST be included in the list of normative references. When items are imported from an IANA-maintained MIB module, the corresponding normative reference SHALL point to the on-line version of that MIB module. It's the RFC Editor's policy that all references must be cited in the text. Such citations MUST appear in the overview section, where documents containing imported definitions (other than those already mentioned in the MIB boilerplate) are required to be mentioned (cf. Section 3.2).
In general, each normative reference SHOULD point to the most recent version of the specification in question. 💖
3.7. Copyright Notices ©️
IETF MIB documents MUST contain the copyright notices and disclaimer specified in Sections 5.4 and 5.5 of RFC 3978 [RFC3978]. Authors and reviewers MUST check to make sure the correct year is inserted into these notices. In addition, the DESCRIPTION clause of the MODULE-IDENTITY invocation of each MIB module that will appear in the published RFC MUST contain a pointer to the copyright notices in the RFC. A template suitable for inclusion in an Internet-Draft, appropriate for MIB modules other than those maintained by the IANA, looks like this:
DESCRIPTION
" [ ... ]
Copyright (C) The Internet Society (date). This version
of this MIB module is part of RFC yyyy; see the RFC
itself for full legal notices."
-- RFC Ed.: replace yyyy with actual RFC number & remove this noteA template suitable for MIB modules that are to be maintained by the IANA looks like this:
DESCRIPTION
" [ ... ]
Copyright (C) The Internet Society (date). The initial
version of this MIB module was published in RFC yyyy;
for full legal notices see the RFC itself. Supplementary
information may be available at:
http://www.ietf.org/copyrights/ianamib.html."
-- RFC Ed.: replace yyyy with actual RFC number & remove this noteIn each case, the current year goes in place of the word "date". 🗓️
3.8. Intellectual Property Section 💜
Section 5 of RFC 3979 [RFC3979] contains a notice regarding intellectual property rights or other rights that must appear in all IETF RFCs. A verbatim copy of that notice SHOULD appear in every IETF MIB document. 🎀
4. SMIv2 Usage Guidelines 🌟
In general, MIB modules in IETF standards-track specifications MUST comply with all syntactic and semantic requirements of SMIv2 [RFC2578] [RFC2579] [RFC2580] that apply to "standard" MIB modules, and except as noted below, SHOULD comply with SMIv2 recommendations. The guidelines in this section are meant to supplement the SMIv2 documents in the following ways:
- to document the current generally accepted interpretation when those documents contain ambiguities or contradictions;
- to update recommendations in those documents that practical experience has shown to be out-of-date or otherwise suboptimal;
- to provide guidance in selecting SMIv2 options where there is consensus on a preferred approach.
4.1. Module Names 🏷️
RFC 2578 Section 3 specifies the rules for module names. Note in particular that names of "standard" modules MUST be unique, MUST follow the syntax rules in RFC 2578 Section 3, and MUST NOT be changed when a MIB module is revised (see also RFC 2578 Section 10).
It is RECOMMENDED that module names be mnemonic. See Appendix C for suggested naming conventions. ✨
4.2. Descriptors, TC Names, and Labels 💅
Okay bestie, so RFC 2578 Sections 3.1, 7.1.1, and 7.1.4 and RFC 2579 Section 3 say descriptors and names in macro invocations, plus labels on enumerated INTEGER and BITS values, should be no longer than 32 characters. But they also require no longer than 64 characters. 🫶 So one number is the vibe and the other is the actual rule 😭
Keeping things to 32 characters clashes with wanting names to be mnemonic, and with wanting descriptors and TC names to be unique (see RFC 2578 Section 3.1 and RFC 2579 Section 3). ✨ The MIB reviewer crowd currently agrees that the 32-character recommendation SHOULD be set aside so we can get clarity and uniqueness, and tools like MIB compilers SHOULD NOT throw warnings for it by default. 🌸
Heads up: violations of the 64-character limit MUST NOT be ignored. They MUST be treated as errors. 🚨
See Appendix C for suggested descriptor and TC naming conventions. 🎀
4.3. Naming Hierarchy 🌳
RFC 2578 Section 4 walks through the object identifier subtrees that IANA maintains and what each one is for. The mgmt subtree { iso 3 6 1 2 } is for IETF "standard" objects, and the experimental subtree { iso 3 6 1 3 } is for objects still cooking in the IETF. 🧁 When a MIB module enters the IETF standards track, it is REQUIRED that its objects get moved from the experimental subtree to the mgmt subtree. 🚀
Moving objects around is a whole nightmare once they've been used at scale in a live environment, so any object headed for operational deployment MUST NOT be registered under the experimental subtree, no matter what its standardization status is. 💀 The experimental subtree should be used only for objects meant for limited experimental deployment, and those usually get defined in Experimental RFCs. 🧪
Note: the word "object," here and in RFC 2578 Section 4, is meant broadly. It covers any construct that results in an OBJECT IDENTIFIER registration. The list of those constructs is in RFC 2578 Section 3.6. 🔍
4.4. IMPORTS Statement 📦
RFC 2578 Section 3.2 spells out which symbols must be imported, and it also lists some predefined symbols that must not be imported. 🙃
The big rule is that if you use an external symbol that isn't a predefined ASN.1 type or the BITS construct, it MUST be mentioned in the module's IMPORTS statement. The phrase "external object" in the first paragraph of that section might make you think that only symbols pointing at object definitions count, but that's not the case, as the later paragraphs make clear. 🫠
Now, RFC 2580 Sections 5.4.3 and 6.5.2 grant exemptions for descriptors of objects that show up in the OBJECT clause of a MODULE-COMPLIANCE statement or in the VARIATION clause of an AGENT-CAPABILITIES statement. Some MIB compilers also exempt notification descriptors in a VARIATION clause, plus descriptors of object groups and notification groups referenced by a MANDATORY-GROUPS clause, a GROUP clause, or an INCLUDES clause. RFC 2580 doesn't mention those cases, though, which is an apparent oversight. 👀 People often find these exemptions unhelpful, since they make IMPORTS rules more complicated and inter-module dependencies less obvious. 😵💫 External symbols referenced by compliance statements and capabilities statements MAY therefore be listed in the IMPORTS statement, and if you do list them, you SHOULD do it consistently. 🧠
Finally, even though the SMI doesn't forbid it, importing symbols you never use is considered poor style, so standards-track MIB modules SHOULD NOT do that. 🙅♀️
4.5. MODULE-IDENTITY Invocation 🪪
RFC 2578 Section 3 requires that every SMIv2 MIB module start with exactly one invocation of the MODULE-IDENTITY macro. That invocation MUST appear immediately after the IMPORTS statement. 💖
RFC 2578 Section 5 describes how the various clauses get used. These extra guidelines apply to all MIB modules that the IETF has change control over: 👑
- If an IETF working group developed the module, then the ORGANIZATION clause MUST give the full name of the working group, and the CONTACT-INFO clause MUST include the working group's mailing list info. The CONTACT-INFO clause SHOULD also point to the working group's web page. 🌈
- A REVISION clause MUST be present for each revision of the MIB module, and the UTC time of the most recent REVISION clause MUST match the LAST-UPDATED clause. The DESCRIPTION clause for each revision MUST state which RFC that revision appeared in, and it SHOULD list all the significant changes. When a MIB module gets revised, the UTC times in all REVISION clauses SHOULD be updated to four-digit year notation. 🗓️
- The value assigned to the MODULE-IDENTITY descriptor MUST be unique, and (for IETF standards-track MIB modules) it SHOULD sit under the
mgmtsubtree [RFC2578]. Most often it'll be an IANA-assigned value directly undermib-2[RFC2578]. For media-specific MIB modules that extend the IF-MIB [RFC2863], though, it's customary to use an IANA-assigned value undertransmission[RFC2578]. In the past some IETF working groups made their own assignments from subtrees IANA delegated to them, but that practice has proven problematic and is NOT RECOMMENDED. 🙅♀️
While a MIB module is still under development, the RFC number it'll eventually be published in is usually unknown, so the RFC Editor has to fill it in before publication. 🪄 An appropriate form for the REVISION clause on a version under development would look something like this:
REVISION "200212132358Z" -- December 13, 2002
DESCRIPTION "Initial version, published as RFC yyyy."
-- RFC Ed.: replace yyyy with actual RFC number & remove this noteNote that after RFC publication, a REVISION clause only shows up for published versions of a MIB module, not for interim versions that lived only as Internet-Drafts. 📝 So a draft version of a MIB module MUST contain just one new REVISION clause that covers all changes since the last published version (if there is one). ✨
When the initial version of a MIB module is still under development, the MODULE-IDENTITY descriptor's value will be unknown if you're using an IANA-assigned value, because the assignment only happens right before publication as an RFC. 🥺 The accepted form for the MODULE-IDENTITY statement in draft versions looks something like this:
<descriptor> MODULE-IDENTITY
[ ... ]
::= { <subtree> XXX }
-- RFC Ed.: replace XXX with IANA-assigned number & remove this noteHere, <descriptor> is whatever descriptor was picked for the module, and <subtree> is the subtree the module will be registered under (for example, mib-2 or transmission). Note that XXX has to be temporarily swapped for a number so the module can compile. 🧩
Note well: before the IANA officially assigns a number, a draft document MUST use a placeholder (like "XXX" above) instead of an actual number. 🛑 If you want trial implementations during development, you may get an assignment under the 'experimental' subtree from the IANA (cf. Section 4.3). 🧪
4.6. Textual Conventions and Object Definitions 🎀
4.6.1. Usage of Data Types 🧩
Keep going, bestie, we're almost at the good stuff! 💜
4.6.1.1. INTEGER, Integer32, Gauge32, and Unsigned32 ✨
okay bestie, so the 32-bit integer types INTEGER, Integer32, Gauge32, and Unsigned32 are all described in RFC 2578 Section 2, and they get the full glow-up in RFC 2578 Sections 7.1.1, 7.1.7, and 7.1.11 🎀. When you're picking one for an object definition or a textual convention, here's the tea:
- For integer-valued enumerations:
- INTEGER is REQUIRED;
- Integer32, Unsigned32, and Gauge32 MUST NOT be used.
ngl, RFC 2578 recommends (but doesn't require) that integer-valued enumerations start at 1 and be numbered contiguously 🌸. This recommendation SHOULD be followed unless there's a valid reason to do otherwise, e.g., to match values of external data or to indicate special cases, and any special-case usage SHOULD be clearly documented 📝. For an example, check out the InetAddressType TC [RFC4001] 💅.
The SMI does allow DEFVAL clauses for integer-valued enumerations to set the default either by label or by numeric value, but the label form is preferred 🧚. Why? All the examples in RFC 2578 use it, and some tools don't accept the numeric form 🙈.
- If the value range is between
-2147483648..2147483647(inclusive) and negative values are possible, then:- Integer32 is RECOMMENDED;
- INTEGER is acceptable;
- Unsigned32 and Gauge32 MUST NOT be used.
- If the value range is between
0..4294967295(inclusive) and the value of the information being modelled may increase above the maximum value or decrease below the minimum value, then:- Gauge32 is RECOMMENDED;
- Unsigned32 is acceptable;
- INTEGER and Integer32 MUST NOT be used if values greater than 2147483647 are possible.
- If the value range is between
0..4294967295(inclusive), and values greater than 2147483647 are possible, and the value of the information being modelled does not increase above the maximum value nor decrease below the minimum value, then:- Unsigned32 is RECOMMENDED;
- Gauge32 is acceptable;
- INTEGER and Integer32 MUST NOT be used.
- If the value range is between
0..2147483647(inclusive), and the value of the information being modelled does not increase above the maximum value nor decrease below the minimum value, then:- Unsigned32 is RECOMMENDED;
- INTEGER, Integer32, and Gauge32 are acceptable.
- For integer-valued objects that appear in an INDEX clause, or for integer-valued TCs that are going to be used in an index column:
- Unsigned32 with a range that excludes zero is RECOMMENDED for most index objects. It is acceptable to include zero in the range when it is semantically significant or when it is used as the index value for a unique row with special properties. Such usage SHOULD be clearly documented in the DESCRIPTION clause.
- Integer32 or INTEGER with a non-negative range is acceptable. Again, zero SHOULD be excluded from the range except when it is semantically significant or when it is used as the index value for a unique row with special properties, and in such cases the usage SHOULD be clearly documented in the DESCRIPTION clause.
- Use of Gauge32 is acceptable for index objects that have gauge semantics.
All of this combines the usage rules for integer data types with the INDEX rules in RFC 2578 Section 7.7, up to and including bullet (1), plus the next-to-last paragraph on page 28 📖.
Sometimes an external variable needs to represent the value of an index object, e.g., ifIndex [RFC2863] 🦋. In those cases, the module authors who own that object SHOULD consider defining TCs such as InterfaceIndex and/or InterfaceIndexOrZero [RFC2863] ✨.
Heads up: INTEGER is a predefined ASN.1 type, so it MUST NOT be present in a module's IMPORTS statement. Integer32, Gauge32, and Unsigned32 are defined by SNMPv2-SMI, though, so they MUST be imported from that module if you use them 💜.
4.6.1.2. Counter32 and Counter64 🔥
Counter32 and Counter64 have special semantics, described in RFC 2578 Sections 7.1.6 and 7.1.10 respectively 💅. Object definitions MUST (and textual conventions SHOULD) respect these semantics. Here's what that means:
- It's OK to use Counter32/64 for counters that may/will be reset when the management subsystem is re-initialized, or when other unusual/irregular events occur (e.g., counters maintained on a line card may be reset when the line card is reset) 🌈. However, if it's possible for those other unusual/irregular events to happen, the DESCRIPTION clause MUST state that this is so, and MUST describe those events in enough detail that a management application can work out whether a reset has happened since the last time the counter was polled 🔍. The RECOMMENDED way to do this is a discontinuity indicator, as described in RFC 2578 Sections 7.1.6 and 7.1.10 🎀. For an example of one, look at the ifCounterDiscontinuityTime object in the IF-MIB [RFC2863] ✨.
- It is NOT OK to put in the DESCRIPTION clause of a Counter32/64 that there is a requirement that, on a discontinuity, the counter MUST reset to zero or to any other specific value 🙅♀️.
- It is NOT OK to put in the DESCRIPTION clause of a Counter32/64 that there is a requirement that it MUST reset at any specific time/event (e.g., midnight) 🕛.
- It is NOT OK for one manager to ask the agent to reset the value(s) of counter(s) to zero, and Counter32/64 is the wrong syntax for "counters" that reset themselves to zero on a regular basis 💀. For the latter, it's better to define or use textual conventions like the ones in RFC 3593 [RFC3593] or RFC 3705 [RFC3705] 🧚.
RFC 2578 Section 7.1.10 puts a requirement on "standard" MIB modules: the Counter64 type may be used only if the information being modelled would wrap in less than one hour if the Counter32 type was used instead 🕐. But now SNMPv3 is an Internet Standard and SNMPv1 is Historic (see http://www.rfc-editor.org/rfcxx00.html for status, and [RFC3410] for the rationale) 📚, so there's no reason to keep enforcing that restriction 🙌. From here on, "standard" MIB modules MAY use the Counter64 type when it makes sense to do so, and MUST use Counter64 if the information being modelled would wrap in less than one hour if the Counter32 type was used instead ⭐. Also, there's no longer a requirement to define Counter32 counterparts for each Counter64 object, although you're still allowed to do it 🦋.
There are also closely-related textual conventions called ZeroBasedCounter32 and ZeroBasedCounter64, defined in RMON2-MIB [RFC2021] and HCNUM-TC [RFC2856], respectively 🌸.
The only difference between ZeroBasedCounter32/64 TCs and Counter32/64 is their starting value. At time=X, where X is their minimum-wrap-time after they were created, ZeroBasedCounter32/64 behaves exactly the same as Counter32/64 ⏳. So the preceding paragraphs and rules apply not just to Counter32/64, but also to ZeroBasedCounter32/64 TCs 🫶.
4.6.1.3. CounterBasedGauge64 💜
SMIv2 unfortunately doesn't provide 64-bit integer base types 😭. To make up for that, the CounterBasedGauge64 textual convention is defined in HCNUM-TC [RFC2856] ✨. This TC uses Counter64 as its base type, but it throws out the special counter semantics, which is allowed under the generally accepted interpretation of RFC 2579 Section 3.3 🎀. It does inherit all the syntactic restrictions of that type, which means it MUST NOT be subtyped, objects defined with it MUST NOT appear in an INDEX clause, MUST NOT have a DEFVAL clause, and MUST have a MAX-ACCESS of read-only or accessible-for-notify 🔒.
This TC SHOULD be used for object definitions that need a 64-bit unsigned data type with gauge semantics 📊. If you need a 64-bit unsigned data type with different semantics, then a different TC based on Counter64 MUST be used, since one TC cannot refine another (cf. RFC 2579 Section 3.5) 🙅♀️.
4.6.1.4. OCTET STRING 🧵
The OCTET STRING type is described in RFC 2578 Section 7.1.2 💖. It represents arbitrary binary or textual data whose length is between 0 and 65535 octets inclusive 📏. Objects and TCs with a SYNTAX of this type SHOULD have a size constraint when the actual bounds are more restrictive than the SMI-imposed limits, and this is especially true for index objects 🗂️. But size constraints SHOULD NOT be imposed arbitrarily, because the SMI doesn't let you change them afterward 🙈.
There are a bunch of standard TCs that cover some of the more common needs for specialized OCTET STRING types 🌈. In particular, SNMPv2-TC [RFC2579] has the DisplayString, PhysAddress, MacAddress, and DateAndTime TCs; the SNMP-FRAMEWORK-MIB [RFC3411] has the SnmpAdminString TC; and the SYSAPPL-MIB [RFC2287] has the Utf8String and LongUtf8String TCs 🧚. When a standard TC gives you the semantics you want, it SHOULD be used in an object's SYNTAX clause instead of OCTET STRING or an equivalent locally-defined TC 🫶.
OCTET STRING is a predefined ASN.1 type, so it MUST NOT be present in a module's IMPORTS statement 🚫.
4.6.1.5. OBJECT IDENTIFIER 🦋
The OBJECT IDENTIFIER type is described in RFC 2578 Section 7.1.3 ✨. Its instances represent administratively assigned names 📛. Heads up: both the SMI and the SNMP protocol limit instances of this type to 128 sub-identifiers, and they require each sub-identifier to be within the range 0..4294967295 inclusive 🔢. Subtyping is not allowed 🙅♀️.
The whole point of OBJECT IDENTIFIER values is to give authoritative identification, either for some type of item or for a specific instance of some type of item 🔑. Things you can identify this way include definitions in MIB modules created with the MODULE-IDENTITY, OBJECT-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, OBJECT-GROUP, NOTIFICATION-GROUP, MODULE-COMPLIANCE, and AGENT-CAPABILITIES constructs 🌸. You can also identify instances of objects defined in MIB modules, protocols, languages, specifications, interface types, hardware, and software 💻. Other options exist for some of these uses, e.g., OCTET STRING or enumerated INTEGER values 🤷♀️. The OBJECT IDENTIFIER type SHOULD be used instead of those alternatives when the set of identification values needs to be independently extensible, without needing a registry for centralized coordination 🌈.
There are also a number of standard TCs for some of the more common needs of specialized OBJECT IDENTIFIER types 💅. In particular, SNMPv2-TC [RFC2579] has the AutonomousType, VariablePointer, and RowPointer TCs 🎀. When a standard TC gives you the desired semantics, it SHOULD be used in an object's SYNTAX clause instead of OBJECT IDENTIFIER or an equivalent locally-defined TC ✨.
OBJECT IDENTIFIER is a predefined ASN.1 type, so it MUST NOT be present in a module's IMPORTS statement ⚠️.
4.6.1.6. The BITS Construct 🧩
The BITS construct is described in RFC 2578 Section 7.1.4 🎀. It represents an enumeration of named bits 🔘. The bit positions in a TC or object definition whose SYNTAX is of this type MUST start at 0 and SHOULD be contiguous 📍.
BITS is defined by the macros that use it, so it MUST NOT be present in a module's IMPORTS statement 🙅♀️.
4.6.1.7. IpAddress 🌐
The IpAddress type described in RFC 2578 Section 7.1.5 SHOULD NOT be used in new MIB modules 🙅♀️. Instead, the InetAddress/InetAddressType textual conventions [RFC4001] SHOULD be used 💖✨.
4.6.1.8. TimeTicks ⏰
Okay so TimeTicks is the type described in RFC 2578 Section 7.1.8 🕰️. It counts the time in hundredths of a second between two epochs, reduced modulo 2^32 ✨. It MUST NOT be subtyped 🙅♀️, and the DESCRIPTION clause of any object or TC whose SYNTAX is of this type MUST identify the reference epochs 💅.
The TimeTicks type SHOULD NOT be used directly in definitions of objects that are snapshots of sysUpTime [RFC3418] 🙈. The TimeStamp TC [RFC2579] already gives you the vibe you want, so it SHOULD be used instead 💖.
4.6.1.9. TruthValue ✅❌
The TruthValue TC is defined in SNMPv2-TC [RFC2579] 📚. It's an enumerated INTEGER type that assumes the values true(1) and false(2) 🫶.
This TC SHOULD be used in the SYNTAX clause of object definitions that require a Boolean type 🎀. MIB modules SHOULD NOT use enumerated INTEGER types or define TCs that duplicate its semantics. Don't be that person 💀.
4.6.1.10. Other Data Types 🧺
There are a bunch of standard TCs that cover the more common needs for specialized data types ✨. Some were already mentioned above, and Appendix B has a partial list that includes those plus some others that are a bit more niche 🌸. There's an on-line version of that list, which gets updated as new TCs are developed, at http://www.ops.ietf.org/mib-common-tcs.html 🔗.
Whenever a standard TC already gives you the semantics you're after, it SHOULD be used in an object definition instead of the corresponding base type or a locally-defined TC 👑. This is especially true of the TCs defined in SNMPv2-TC [RFC2579] and SNMP-FRAMEWORK-MIB [RFC3411], because they are Internet Standards. Modules that refer to them won't get held up on the standards track just because of those references, so it's a total win 🏆.
MIB module authors need to be aware that enumerated INTEGER or BITS TCs may in some cases be extended with additional enumerated values or additional bit positions 🌈. When an imported TC that may be extended like this is used to define an object that may be written, or that serves as an index in a read-create table, then the set of values or bit positions that needs to be supported SHOULD be specified either in the object's DESCRIPTION clause or in an OBJECT clause in the MIB module's compliance statement(s) 🧠. You can do that by explicitly listing the required values or bit positions, or by saying that an implementation may support a subset of values or bit positions of its choosing 🦋.
4.6.2. DESCRIPTION and REFERENCE Clauses 📝
It is hard to overemphasize how important an accurate and unambiguous DESCRIPTION clause is for all objects and TCs 😭. The DESCRIPTION clause holds the instructions implementors will use to build an object. If those instructions are inadequate or ambiguous, implementation quality suffers, and nobody wants that 💔. Probably the single most important job of a MIB reviewer is making sure DESCRIPTION clauses are clear enough to let interoperable implementations get built 🔥.
A super common problem is seeing an object definition for, say, stdMIBPoofpoofCounter with a DESCRIPTION clause that just says "Number of poofpoofs" and never explains what a poofpoof even is 🙃. In situations like that, it is strongly RECOMMENDED to have at least a minimal explanation, or a REFERENCE clause that points to the definition of a poofpoof 🍓.
For read-write objects (other than columns in read-create tables that have well-defined persistence properties), it is RECOMMENDED that the DESCRIPTION clause spell out what happens to the value after an agent reboot 🔄. The possibilities include the value staying unchanged, reverting to a well-defined default value, or the result being implementation-dependent 🎲.
4.6.3. DISPLAY-HINT Clause 🖥️
The DISPLAY-HINT clause is used in a TC to give a nonbinding hint to a management application about how the value of an instance of an object defined with the syntax in that TC might be displayed 👀. Including it is optional 🫧.
Management applications usually default to decimal format ("d") for integer TCs that aren't enumerations, and to a hexadecimal format ("1x:" or "1x " or "1x_") for octet string TCs when the DISPLAY-HINT clause is absent 🔢. Still, SMIv2 doesn't actually specify any defaults, so it's worth knowing that. MIB authors should be aware that a clear hint is only provided to applications when the DISPLAY-HINT clause is present 💫.
4.6.4. Conceptual Table Definitions 🗂️
RFC 2578 Sections 7.1.12 and 7.1.12.1 spell out the rules for defining conceptual tables 📖, and RFC 2578 Sections 7.7, 7.8, and 7.8.1 cover the conceptual table indexing rules 🧩. The following guidelines apply to those definitions:
- For conceptual rows:
- If the row is an extension of a row in some other table, then an AUGMENTS clause MUST be used if the relationship is one-to-one, and an INDEX clause MUST be used if the relationship is sparse. In the latter case, the INDEX clause SHOULD be identical to that of the original table 💕.
- If the row is an element of an expansion table (meaning multiple row instances correspond to a single row instance in some other table), then an INDEX clause MUST be used, and the first-mentioned elements SHOULD be the indices of that other table, listed in the same order 🪜.
- If objects external to the row are present in the INDEX clause, then the conceptual row's DESCRIPTION clause MUST specify how those objects are used in identifying instances of its columnar objects. In particular, it MUST specify for which values of those index objects the conceptual row may exist 🎯.
- Use of the IMPLIED keyword is NOT RECOMMENDED for any index object that may appear in the INDEX clause of an expansion table 🚫. Since this keyword may only be associated with the last object in an INDEX clause, it can't be associated with the same index object in a primary table and an expansion table. That would make the sort order different in the primary table and any expansion tables. As a result, an implementation can't reuse indexing code from the primary table in expansion tables, and data structures meant to be extended might have to be replicated 😩. Designers who are tempted to use IMPLIED should think about this: the resulting sort order rarely meets user expectations, especially for strings with both uppercase and lowercase letters, and it doesn't take the user language or locale into account 🌍.
- If dynamic row creation and/or deletion by management applications is supported, then:
- There SHOULD be one columnar object with a SYNTAX value of RowStatus [RFC2579] and a MAX-ACCESS value of read-create. This object is called the status column for the conceptual row 🚦. All other columnar objects MUST have a MAX-ACCESS value of read-create, read-only, accessible-for-notify, or not-accessible. A MAX-ACCESS value of read-write is not allowed 🙅♀️.
- There either MUST be one columnar object with a SYNTAX value of StorageType [RFC2579] and a MAX-ACCESS value of read-create, or else the row object (table entry) DESCRIPTION clause MUST specify what happens to dynamically-created rows after an agent restart 🔁.
- If the agent itself may also create and/or delete rows, then the conditions under which this can happen MUST be clearly documented in the row object DESCRIPTION clause 📣.
- For conceptual rows that include a status column:
- The DESCRIPTION clause of the status column MUST specify which columnar objects (if any) have to be set to valid values before the row can be activated. If any objects in cascading tables have to be populated with related data before the row can be activated, then this MUST also be specified 🧁.
- The DESCRIPTION clause of the status column MUST specify whether or not it is possible to modify other columns in the same conceptual row when the status value is
active(1)⚡. Note that in many cases it will be possible to modify some writable columns when the row is active but not others. In such cases, the DESCRIPTION clause for each writable column SHOULD state whether or not that column can be modified when the row is active. The DESCRIPTION clause for the status column SHOULD state that modifiability of other columns when the status value isactive(1)is specified in the DESCRIPTION clauses for those columns, rather than listing the modifiable columns individually 🫧.
- For conceptual rows that include a StorageType column:
- The DESCRIPTION clause of the StorageType column MUST specify which read-write or read-create columnar objects in
permanent(4)rows an agent must, at a minimum, allow to be writable 🔒.
- The DESCRIPTION clause of the StorageType column MUST specify which read-write or read-create columnar objects in
Note that RFC 2578 Section 7.8 requires that the lifetime of an instance of a conceptual row that AUGMENTS a base row must be the same as the corresponding instance of the base row 🧬. So there's no need for a RowStatus or StorageType column in an augmenting row if one is already present in the base row 🙌.
Complete requirements for the RowStatus and StorageType TCs can be found in RFC 2579, in the DESCRIPTION clauses for those TCs 📕.
4.6.5. OID Values Assigned to Objects 🔢
RFC 2578 Section 7.10 specifies the rules for assigning OBJECT IDENTIFIER (OID) values to OBJECT-TYPE definitions 🎫. In particular:
- A conceptual table MUST have exactly one subordinate object, which is a conceptual row. The OID assigned to the conceptual row MUST be derived by appending a sub-identifier of
"1"to the OID assigned to the conceptual table 🌷. - A conceptual row has as many subordinate objects as there are columns in the row, and there MUST be at least one. The OID assigned to each columnar object MUST be derived by appending a non-zero sub-identifier, unique within the row, to the OID assigned to the conceptual row 🧵.
- A columnar or scalar object MUST NOT have any subordinate objects 🚫.
- The last sub-identifier of an OID assigned to any object (be it table, row, column, or scalar) MUST NOT be equal to zero. Note that sub-identifiers of intermediate nodes MAY be equal to zero 🌈.
- The OID assigned to an object definition MUST NOT also be assigned to another definition that results in OID registration. RFC 2578 Section 3.6 lists the constructs that create OID registrations 📋.
Although the SMI doesn't specifically require it, it is customary (and strongly RECOMMENDED) that object definitions not be registered beneath group definitions, compliance statements, capabilities statements, or notification definitions 🙅♀️. It is also customary (and strongly RECOMMENDED) that group definitions, compliance statements, capabilities statements, and notification definitions not be registered beneath object definitions 🫶. See Appendix D for a RECOMMENDED OID assignment scheme 🗺️.
4.6.6. OID Length Limitations and Table Indexing ✨
okay so, as RFC 2578 Section 3.5 spells out, every OID is capped at 128 sub-identifiers 🙈 that sounds like a lot, and for administrative assignments it's usually totally fine 💅. but it does mess with table indexing, bestie 😭. the cap also applies to OIDs for object instances, and those are just the "base" OID from the object definition glued together with the index components. so when a table has several indices of types like OCTET STRING or OBJECT IDENTIFIER that each turn into multiple sub-identifiers, you can hit 128 suuuper fast 💀
and no, you can't just ignore it 🚫. the cap comes from the SMI and ALSO from SNMP (see the last paragraph in Section 4.1 of RFC 3416 [RFC3416]). so any table with enough index components to break the limit can't be read or written using SNMP at all, which makes it unusable 😩. table design MUST take the 128-sub-identifier limit into account 🎀. it's RECOMMENDED that all MIB documents spell out any limitations on index component lengths that management software needs to observe 🌸. you can do that by putting SIZE constraints on the index components, or by specifying the applicable constraints in the conceptual row DESCRIPTION clause or in the surrounding documentation ✨.
4.7. Notification Definitions 🔔
RFC 2578 Section 8 is the rulebook for notification definitions 📜. the big rules are:
- Inaccessible objects MUST NOT appear in the
OBJECTSclause. 🙅♀️ - For each object type mentioned in the
OBJECTSclause, theDESCRIPTIONclause MUST specify which object instance is to be present in the transmitted notification, and MUST specify the information/meaning conveyed. 📝 - The OBJECT IDENTIFIER (OID) value assigned to each notification type MUST have a next-to-last sub-identifier of zero 🔢. this is so you can convert an SMIv2 notification definition into an SMIv1 trap definition and back again without losing information (see [RFC3584] Section 2.1.2). it also makes it possible for a multilingual proxy chain to translate an SNMPv2 trap into an SNMPv1 trap and back again without losing information (see [RFC3584] Section 3) 🦋. and the OID assigned to a notification definition MUST NOT also be assigned to another definition that results in OID registration. RFC 2578 Section 3.6 lists the constructs that create OID registrations 📋.
the SMI doesn't specifically require the next bit, but it's customary (and strongly RECOMMENDED) that notification definitions NOT get registered beneath group definitions, compliance statements, capabilities statements, or object definitions 🙃. the object one is especially unwise, because it can end up with an object instance and a notification definition sharing the same OID 💀. it's also customary (and strongly RECOMMENDED) that the OIDs assigned to notification types be leaf OIDs, meaning there are no OID registrations subordinate to a notification definition 🍃. see Appendix D for a RECOMMENDED OID assignment scheme 🧚.
okay now the throttling drama 😤. a lot of notifications get triggered by external events, and sometimes those events can happen so fast that sending a notification for each one would flood the network 🌊. so in those cases a mechanism MUST be provided for limiting the rate at which the notification can be generated 🚦. the common move is to make the notification generator use throttling, which means it generates no more than one notification for each event source in any given time interval of duration T ⏱️. the throttling period T MAY be configurable, in which case it's specified in a MIB object, or it MAY be fixed, in which case it's specified in the notification definition 💜. examples of the fixed time interval technique live in the SNMP-REPEATER-MIB [RFC2108] and the ENTITY-MIB [RFC4133] ✨.
4.8. Compliance Statements 📜
RFC 2580 Sections 3, 4, and 5 are where the rules for conformance groups and compliance statements live 💅. the big ones:
- Every object with a
MAX-ACCESSvalue other than"not-accessible"MUST be contained in at least one object group 🫶. - Every notification MUST be contained in at least one notification group 🔔.
- There MUST be at least one compliance statement defined for each "standard" MIB module 🌈. it can live either within that MIB module or within a companion MIB module 🏠.
okay, now the sneaky stuff that people totally miss when writing compliance statements 👀:
- an object group or notification group that isn't mentioned in the
MANDATORY-GROUPSclause or in anyGROUPclause of aMODULE-COMPLIANCEstatement is unconditionally optional with respect to that compliance statement 😳. another way to say a group is optional is to mention it in aGROUPclause whoseDESCRIPTIONclause states that the group is optional. that second way is RECOMMENDED (for optional groups that are relevant to the compliance statement) so it's super clear the optional status is intended and not just an accident of forgetting 🙈. - if there are any objects with a
MAX-ACCESSvalue ofread-writeorread-createthat have noOBJECTclause specifying aMIN-ACCESSofread-only, then implementations have to support write access to those objects to be compliant with thatMODULE-COMPLIANCEstatement 😱. this catches MIB module authors off guard all the time. when you run into this, reviewers SHOULD verify that this is really what the authors intended, because it often isn't 🕵️♀️. - on the flip side, MIB module authors need to know that a read-only compliance statement is enough to support interoperable monitoring applications, but it is NOT enough to support interoperable configuration applications 🛠️. a technique that's commonly used in MIB modules meant to support both monitoring and configuration is to provide both a read-only compliance statement and a full compliance statement 👑. a good example is the DIFFSERV-MIB [RFC3289]. authors SHOULD consider using this technique when it applies 💖.
sometimes MIB module authors want to say that a compliant implementation only needs to support a subset of the values allowed by an object's SYNTAX clause 🍓. for accessible objects, you can do that either by specifying the required values in an object's DESCRIPTION clause, or by providing an OBJECT clause with a refined SYNTAX in a compliance statement. the second method is RECOMMENDED for most cases, and is REQUIRED if there are multiple compliance statements with different value subsets required 🎯. the DIFFSERV-MIB [RFC3289] shows this off nicely. the diffServMIBFullCompliance statement contains this OBJECT clause (see Section 4.8.1, "Note Regarding These Examples and RFC 2578"):
OBJECT diffServDataPathStatus
SYNTAX RowStatus { active(1) }
WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) }
DESCRIPTION
"Support for createAndWait and notInService is not required."and the diffServMIBReadOnlyCompliance statement contains this one 👇:
OBJECT diffServDataPathStatus
SYNTAX RowStatus { active(1) }
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and active is the only status that
needs to be supported."you can't do this for inaccessible index objects, because they can't be present in object groups and can't be mentioned in OBJECT clauses 🚫. but there are situations where you might want to say an implementation only has to support a subset of the possible values of some index in a read-create table 🧩. in those cases, the requirements MUST be specified either in the index object's DESCRIPTION clause (RECOMMENDED if there is only one value subset) or in the DESCRIPTION clause of a MODULE-COMPLIANCE statement (REQUIRED if the value subset is unique to the compliance statement) 💜.
in lots of cases, a MIB module always gets implemented alongside one or more other MIB modules 👯. that fact is REQUIRED to be noted in the surrounding documentation (see Section 3.2 above), and it SHOULD also be noted in the relevant compliance statements 📝. when a particular compliance statement in (say) MIB module A requires the complete implementation of some other MIB module B, the RECOMMENDED approach is to include a statement to that effect in the DESCRIPTION clause of the compliance statement(s) in MIB module A 🌸. it's also possible that MIB module A has requirements that differ from anything expressed by a compliance statement of module B. for example, module A might not require any of the unconditionally mandatory object groups from module B, but might require mandatory implementation of an object group from module B that's only conditionally mandatory with respect to the compliance statement(s) in module B 🌀. in those cases, the RECOMMENDED approach is for the compliance statement(s) in module A to formally specify requirements with respect to module B using the appropriate MODULE, MANDATORY-GROUPS, GROUP, and OBJECT clauses 🧠. an example is the compliance statements in the DIFFSERV-MIB [RFC3289], which list the ifCounterDiscontinuityGroup from IF-MIB [RFC2863] as a mandatory group. that group isn't enough to satisfy any IF-MIB compliance statement, and it's conditionally mandatory in the IF-MIB's current compliance statement ifCompliance3 🥹.
4.8.1. Note Regarding These Examples and RFC 2578 💭
there's been some debate about whether syntax refinements that restrict enumerations (RFC 2578 Section 9) are allowed with TCs, like in the examples above, or only with the base types INTEGER and BITS, which is what a strict reading of RFC 2578 suggests 🤔. the rough consensus of the SMIv2 editors and the current pool of MIB reviewers is that they're supposed to be allowed with TCs ✨. MIB module authors want to be aware that some MIB compilers follow the strict reading of RFC 2578 and require the TC to be replaced by its base type (INTEGER or BITS) when enumerations are refined 🛠️. that usage is legal, and you can find it in some older MIB modules, like the IF-MIB [RFC2863] 🍰.
4.9. Revisions to MIB Modules 🎀
okay so RFC 2578 Section 10 has general rules that kick in every single time a MIB module gets revised 💅 Specifically:
- bestie, the
MODULE-IDENTITYinvocation MUST be updated to include info about the revision 📝 TheLAST-UPDATEDclause value MUST be set to the revision time, aREVISIONclause with that same UTC time MUST be added along with aDESCRIPTIONclause describing the changes, and any obsolete info in the existingDESCRIPTION,ORGANIZATION, andCONTACT-INFOclauses MUST be replaced with up-to-date info. Also check Section 4.5 above for extra rules if the MIB module is under IETF change control 🔥 - on the other hand 🙈 the module name MUST NOT be changed (except to fix typos), existing definitions (even obsolete ones) MUST NOT be removed from the MIB module, and descriptors and
OBJECT IDENTIFIERvalues tied to existing definitions MUST NOT be changed or re-assigned. hard no, periodt 🚫
okay the reason we forbid certain changes is so important 🧚 A revised MIB module has to stay compatible with fielded implementations based on older versions. There are two distinct kinds of backward compatibility here. One is "over the wire" compatibility, which means agent and manager implementations based on different revisions can still talk to each other. The other is "compilation" compatibility, which means MIB modules that import definitions from the revised module still compile. The rules about not changing or re-assigning OBJECT IDENTIFIER values are there for "over the wire" compatibility, and the rules about module names, descriptors, and removing obsolete definitions are there for compilation compatibility 💜
RFC 2578 Section 10.2 has rules for revising object definitions. These guidelines fix some errors in those rules and add a few clarifications ✨
- bullet (1) lets the labels of named numbers and named bits in
SYNTAXclauses of type enumeratedINTEGERorBITSbe changed. That can break compilation compatibility, since those labels may be used byDEFVALclauses in modules that import the definitions of the affected objects. So labels of named numbers and named bits MUST NOT be changed when revising IETF MIB modules (except to correct typographical errors), and they SHOULD NOT be changed when revising enterprise MIB modules 🙅♀️ - although bullets (1) through (8) don't specifically permit it, it's generally considered fine to add range constraints to the
SYNTAXclause of an integer-valued object, as long as the constraints just make explicit some value restrictions that were already implicit in the definition of the object. The most common example is an auxiliary object with aSYNTAXofINTEGERorInteger32and no range constraint. An auxiliary object isn't allowed to assume negative values, so adding the range constraint(0..2147483647)can't possibly result in any "over the wire" change, and it won't cause any compilation compatibility problems with a correctly written MIB module. Such a change SHOULD be treated by a reviewer as an editorial change, not as a semantic change 🧐 Similarly, removing a range or size constraint from an object definition when that constraint is enforced by the underlying data type SHOULD be treated by a reviewer as an editorial change too 💅
RFC 2578 Section 10.3 has rules for revising notification definitions. No clarifications or corrections are required there ✅
RFC 2579 Section 5 has rules for revising textual convention definitions. This guideline fixes an error in those rules:
- bullet (1) lets the labels of named numbers and named bits in
SYNTAXclauses of type enumeratedINTEGERorBITSbe changed. That can break compilation compatibility, since those labels may be used byDEFVALclauses in modules that import the definitions of the affected TCs. So labels of named numbers and named bits MUST NOT be changed when revising IETF MIB modules (except to correct typographical errors), and they SHOULD NOT be changed when revising enterprise MIB modules 🙅♀️
RFC 2580 Section 7.1 has rules for revising conformance groups. Two points are worth repeating 🔁
- objects and notifications MUST NOT be added to or removed from an existing object group or notification group. Doing so could cause a compilation failure or (worse) a silent change in the meaning of a compliance statement or capabilities statement that refers to that group 😱
- the status of a conformance group is independent of the status of its members. Thus, a current group MAY refer to deprecated objects or notifications. This may be desirable in certain cases, e.g., a set of widely-deployed objects or notifications may be deprecated when they are replaced by a more up-to-date set of definitions, but the conformance groups that contain them may remain current in order to encourage continued implementation of the deprecated objects and notifications 🦋
RFC 2580 Section 7.2 has rules for revising compliance statements. These guidelines fill in an omission from those rules and emphasize one important point 🕵️
- RFC 2580 should (but does not) recommend that an
OBJECTclause specifying support for the original set of values be added to a compliance statement when an enumeratedINTEGERobject or aBITSobject referenced by the compliance statement has enumerations or named bits added, assuming that no such clause is already present and that the effectiveMIN-ACCESSvalue isread-writeorread-create. This is necessary in order to avoid a silent change to the meaning of the compliance statement. MIB module authors and reviewers SHOULD watch for this to ensure that suchOBJECTclauses are added when needed. Note that this may not always be possible to do, since affected compliance statements may reside in modules other than the one that contains the revised definition(s) 🧩 - the status of a compliance statement is independent of the status of its members. Thus, a current compliance statement MAY refer to deprecated object groups or notification groups. This may be desirable in certain cases, e.g., a set of widely-deployed object or notification groups may be deprecated when they are replaced by a more up-to-date set of definitions, but compliance statements that refer to them may remain current in order to encourage continued implementation of the deprecated groups 🌸
RFC 2580 Section 7.3 has rules for revising capabilities statements. This guideline fills in an omission from those rules:
- RFC 2580 should (but does not) recommend that
VARIATIONclauses specifying support for the original set of values be added to a capabilities statement when enumeratedINTEGERobjects orBITSobjects referenced by the capabilities statement have enumerations added, assuming that no such clauses are already present. This is necessary in order to avoid a silent change to the meaning of the capabilities statement 🎀
In certain exceptional situations, the cost of strictly following the SMIv2 rules governing MIB module revisions may exceed the benefit. In such cases, the rules can be waived, but when that is done both the change and the justification for it MUST be thoroughly documented. One example is provided by Section 3.1.5 of RFC 2863, which documents the semantic change that was made to ifIndex in the transition from MIB-II [RFC1213] to the IF-MIB [RFC2863] and provides a detailed justification for that change. Another example is provided by the REVISION clause of the SONET-MIB [RFC2558] that documents raising the MAX-ACCESS of several objects to read-write while adding MIN-ACCESS of read-only for compatibility with the previous version [RFC1595] 🙌
Authors and reviewers may find it helpful to use tools that can list the differences between two revisions of a MIB module. Please see http://www.ops.ietf.org/mib-review-tools.html for more information 🔍
5. Acknowledgments 🫶
Most of the material on usage of data types was based on input provided by Bert Wijnen with assistance from Keith McCloghrie, David T. Perkins, and Juergen Schoenwaelder. Much of the other material on SMIv2 usage was taken from an unpublished guide for MIB authors and reviewers by Juergen Schoenwaelder. Some of the recommendations in these guidelines are based on material drawn from the on-line SMIv2 errata list at http://www.ibr.cs.tu-bs.de/ietf/smi-errata/. Thanks to Frank Strauss and Juergen Schoenwaelder for maintaining that list and to the contributors who supplied the material for that list. Finally, thanks are due to the following individuals whose comments on earlier versions of this memo contained many valuable suggestions for additions, clarifications, and corrections: Andy Bierman, Bob Braden, Michelle Cotton, David Harrington, Harrie Hazewinkel, Dinakaran Joseph, Michael Kirkham, Keith McCloghrie, David T. Perkins, Randy Presuhn, Dan Romascanu, Juergen Schoenwaelder, Frank Strauss, Dave Thaler, and Bert Wijnen 💖
6. Security Considerations 💀
Implementation and deployment of a MIB module in a system may result in security risks that would not otherwise exist. It is important 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. this is a serious one, bestie, so please don't skip it 🚨
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 ✨
okay so the whole point of a MIB review is to check the MIB module for technical correctness AND for sticking to IETF documentation rules 🧐 this checklist is super helpful when you're reviewing a draft:
- I-D Boilerplate 📝: make sure the draft has the required Internet-Draft boilerplate (see
http://www.ietf.org/ietf/1id-guidelines.txt). That includes the right statement to allow publication as an RFC. Also, the I-D boilerplate must NOT have any references or section numbers 🙅♀️ - Abstract 💌: the abstract shouldn't have references or a section number, and its content should follow the guidelines in
http://www.ietf.org/ietf/1id-guidelines.txt. - MIB Boilerplate 🎀: the draft needs the latest approved SNMP Network Management Framework boilerplate from the OPS area web site (
http://www.ops.ietf.org/mib-boilerplate.html). - Security Considerations Section 🔐: use the latest approved template from the OPS area web site (
http://www.ops.ietf.org/mib-security.html), and follow the guidelines in there. - IANA Considerations Section 🦋: this one must ALWAYS be there. If the draft needs no action from IANA, say so explicitly. If the draft needs OID values assigned, the IANA Considerations section has to include the info from Section 3.5 of these guidelines. If the draft has the initial version of an IANA-maintained module, check that the MODULE-IDENTITY invocation has maintenance instructions that follow the requirements in RFC 2434. In that second case, the IANA Considerations section that shows up in the RFC MUST include a pointer to the actual IANA-maintained module 🫶
- References 📚: make sure the references are properly split into normative and informative ones. RFC 2119 should be a normative reference if the terminology it defines is used in the document. All the references the boilerplate needs should be there. Any MIB modules with imported items need to be cited as normative references. And all citations should point to the most current RFCs, unless there's a valid reason not to. (It's totally fine to include an informative reference to an older version of a spec to explain a feature that's kept for backward compatibility 💅)
- Copyright Notices ©️: the draft should have an abbreviated copyright notice in the DESCRIPTION clause of each MODULE-IDENTITY invocation. It should also have the full copyright notice and disclaimer from Sections 5.4 and 5.5 of RFC 3978 at the end of the document. Double-check that the right year is used in ALL the copyright dates 📅
- IPR Notice ⚖️: if the draft doesn't have a verbatim copy of the IPR notice from Section 5 of RFC 3979, recommend that the IPR notice gets included.
- Other Issues 🕵️♀️: check for anything in
http://www.ietf.org/ID-Checklist.htmlthat isn't already covered somewhere else. - Technical Content 🧠: review the actual technical content against the guidelines in this document. A MIB compiler is recommended for catching syntax errors (see
http://www.ops.ietf.org/mib-review-tools.htmlfor more). BUT syntax is only part of the job. It's just as important to actually read the MIB document the way a potential implementor would. Especially check that the DESCRIPTION clauses are clear and unambiguous enough that interoperable implementations can be built from them 🍓
Appendix B: Commonly Used Textual Conventions 🌸
Here are the TCs 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. (That's always the case if the object is meant for humans [RFC2277].) Designers SHOULD consider using SnmpAdminString, Utf8String, or LongUtf8String for those 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 ✨
Next up, the TC defined in SNMP-FRAMEWORK-MIB [RFC3411]:
SnmpAdminString OCTET STRING (SIZE (0..255))Then the TCs defined in SYSAPPL-MIB [RFC2287]:
Utf8String OCTET STRING (SIZE (0..255))
LongUtf8String OCTET STRING (SIZE (0..1024))The TCs defined in INET-ADDRESS-MIB [RFC4001] are next 🌈
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 INTEGERFrom TRANSPORT-ADDRESS-MIB [RFC3419]:
TransportDomain OBJECT IDENTIFIER
TransportAddressType enumerated INTEGER
TransportAddress OCTET STRING (SIZE (0..255))From RMON2-MIB [RFC2021]:
ZeroBasedCounter32 Gauge32From HCNUM-TC [RFC2856]:
ZeroBasedCounter64 Counter64
CounterBasedGauge64 Counter64From IF-MIB [RFC2863]:
InterfaceIndex Integer32 (1..2147483647)
InterfaceIndexOrZero Integer32 (0..2147483647)From ENTITY-MIB [RFC4133]:
PhysicalIndex Integer32 (1..2147483647)
PhysicalIndexOrZero Integer32 (0..2147483647)From PerfHist-TC-MIB [RFC3593]:
PerfCurrentCount Gauge32
PerfIntervalCount Gauge32
PerfTotalCount Gauge32And last but not least, from 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 Counter64Appendix C: Suggested Naming Conventions 🎀
Authors and reviewers of IETF MIB modules have found these naming conventions helpful in the past, so if you're writing a new IETF MIB module, you're really urged to think about following them 🥹
- The module name should look like XXX-MIB (or XXX-TC-MIB for a module that only has TCs). XXX is a unique prefix (usually all caps with hyphens as separators) that no existing module is using. For example, the module for managing optical interfaces [RFC3591] uses the prefix OPT-IF and has the module name OPT-IF-MIB 🔆
- The descriptor tied to the MODULE-IDENTITY invocation should look like xxxMIB, xxxMib, or xxxMibModule. Here xxx is a mixed-case version of XXX that starts with a lowercase letter and has no hyphens. For example, OPT-IF-MIB uses the prefix optIf, and its MODULE-IDENTITY descriptor is optIfMibModule 💜
- Other descriptors inside the MIB module should all start with the same prefix xxx. OPT-IF-MIB uses the prefix optIf for every descriptor 🧁
- Names of TCs that are specific to the MIB module, and names of SEQUENCE types used in conceptual table definitions, should start with a prefix Xxx. That's the same as xxx but with the first letter made uppercase. OPT-IF-MIB uses the prefix OptIf on its TC and SEQUENCE type names 🦋
- The descriptor for a conceptual table should look like xxxZzzTable. The descriptor for the matching conceptual row should look like xxxZzzEntry. The name of the associated SEQUENCE type should look like XxxZzzEntry. And the descriptors for the subordinate columnar objects should look like xxxZzzSomeotherName. An example from OPT-IF-MIB is the OTMn table 🌟 Its table object descriptor is optIfOTMnTable, its row object descriptor is optIfOTMnEntry, its SEQUENCE type name is OptIfOTMnEntry, and its columnar object descriptors are optIfOTMnOrder, optIfOTMnReduced, optIfOTMnBitRates, optIfOTMnInterfaceType, optIfOTMnTcmMax, and optIfOTMnOpticalReach.
- When you use abbreviations, use them consistently 🙈 Inconsistent usage like this should be avoided:
xxxYyyDestAddr
xxxZzzDstAddrAppendix D: Suggested OID Layout 💅
As noted in RFC 2578 Section 5.6, it's common practice to use the value of the MODULE-IDENTITY invocation as a subtree where the other OBJECT IDENTIFIER values assigned inside the module get defined. That leaves open the question of how OIDs get assigned inside that subtree. One scheme that's gained favour (and that is RECOMMENDED unless there's a specific reason not to use it) puts three separate branches right below the MODULE-IDENTITY value. Those branches are for notification definitions, object definitions, and conformance definitions. The conformance branch then gets split into sub-branches for compliance statements and object/notification groups. Here's how it looks, with naming following Appendix C. The numbers in parentheses are the sub-identifiers given to each branch 🧚
xxxMIB
|
+-- xxxNotifications(0)
+-- xxxObjects(1)
+-- xxxConformance(2)
|
+-- xxxCompliances(1)
+-- xxxGroups(2)With this scheme, notification definition values are assigned right below the xxxNotifications node. That makes sure every 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 can have extra sub-structure, but nothing beyond what Section 4.6.5 above specifies is actually required 🫶
One example of a MIB module whose OID assignments follow this scheme is the POWER-ETHERNET-MIB [RFC3621] 🌈
Normative References ✨
Okay bestie, these are the docs the spec leans on. You can't skip them 💅
[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 🧚
These ones are extra reading. Super useful for context, but not required to make the spec click 🌸
[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 📮
Here's where to find the editor if you've got questions 💌
C. M. Heard
158 South Madison Ave. #207
Pasadena, CA 91101-2569
USA
Phone: +1 626 795 5311
EMail: heard@pobox.comFull Copyright Statement 🎀
The legal bits have to stay word for word, so here they are exactly as written 🫶
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 🦋
Patent and rights stuff, also verbatim so nothing gets fuzzy 🔥
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. 🌈
📦 where this page comes from
- ietf: rfc4181 2005-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms