RFC 3216
SMIng Objectives
RFC 3216: SMIng Objectives 🎀
Okay bestie, let's set the scene 💖 This is RFC 3216, called SMIng Objectives, and it dropped in December 2001. It's an Informational doc from the Network Working Group, so it's giving "here's some info for the community" and not a formal standard 📚 The title block doesn't list anything it obsoletes or updates.
The authors are C. Elliott (Cisco Systems), D. Harrington (Enterasys Networks), J. Jason (Intel Corporation), J. Schoenwaelder (TU Braunschweig), F. Strauss (TU Braunschweig), and W. Weiss (Ellacoya Networks). A whole squad of networking legends 👑
Status of this Memo 📜
This memo gives information to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 🦋
Copyright Notice ©️
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract ✨
Okay so this doc describes the goals for a brand new data definition language 🧚 It's meant for modeling network management stuff, and it has to be something that can be mapped straight into SNMP and COPS-PR protocol operations. Iconic 💅
The point of the doc is to be a wishlist that a later language spec should try to hit. It also captures what the working group agreed on during their discussions toward consensus on the SMIng objectives 🫶
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Specific Objectives for SMIng . . . . . . . . . . . . . . 4
4.1 Accepted Objectives . . . . . . . . . . . . . . . . . . . 5
4.1.1 The Set of Specification Documents . . . . . . . . . . . . 6
4.1.2 Textual Representation . . . . . . . . . . . . . . . . . . 6
4.1.3 Human Readability . . . . . . . . . . . . . . . . . . . . 6
4.1.4 Rigorously Defined Syntax . . . . . . . . . . . . . . . . 6
4.1.5 Accessibility . . . . . . . . . . . . . . . . . . . . . . 7
4.1.6 Language Extensibility . . . . . . . . . . . . . . . . . . 7
4.1.7 Special Characters in Text . . . . . . . . . . . . . . . . 7
4.1.8 Naming . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.9 Namespace Control . . . . . . . . . . . . . . . . . . . . 8
4.1.10 Modules . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.11 Module Conformance . . . . . . . . . . . . . . . . . . . . 9
4.1.12 Arbitrary Unambiguous Identities . . . . . . . . . . . . . 9
4.1.13 Protocol Independence . . . . . . . . . . . . . . . . . . 9
4.1.14 Protocol Mapping . . . . . . . . . . . . . . . . . . . . . 10
4.1.15 Translation to Other Data Definition Languages . . . . . . 10
4.1.16 Base Data Types . . . . . . . . . . . . . . . . . . . . . 10
4.1.17 Enumerations . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.18 Discriminated Unions . . . . . . . . . . . . . . . . . . . 11
4.1.19 Instance Pointers . . . . . . . . . . . . . . . . . . . . 11
4.1.20 Row Pointers . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.21 Constraints on Pointers . . . . . . . . . . . . . . . . . 12
4.1.22 Base Type Set . . . . . . . . . . . . . . . . . . . . . . 12
4.1.23 Extended Data Types . . . . . . . . . . . . . . . . . . . 12
4.1.24 Units, Formats, and Default Values of Defined Types and
Attributes . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.25 Table Existence Relationships . . . . . . . . . . . . . . 13
4.1.26 Table Existence Relationships (2) . . . . . . . . . . . . 14
4.1.27 Attribute Groups . . . . . . . . . . . . . . . . . . . . . 14
4.1.28 Containment . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.29 Single Inheritance . . . . . . . . . . . . . . . . . . . . 15
4.1.30 Reusable vs. Final Attribute Groups . . . . . . . . . . . 15
4.1.31 Events . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.32 Creation/Deletion . . . . . . . . . . . . . . . . . . . . 16
4.1.33 Range and Size Constraints . . . . . . . . . . . . . . . . 16
4.1.34 Uniqueness . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.35 Extension Rules . . . . . . . . . . . . . . . . . . . . . 17
4.1.36 Deprecate Use of IMPLIED Keyword . . . . . . . . . . . . . 17
4.1.37 No Redundancy . . . . . . . . . . . . . . . . . . . . . . 17
4.1.38 Compliance and Conformance . . . . . . . . . . . . . . . . 17
4.1.39 Allow Refinement of All Definitions in Conformance
Statements . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.40 Categories . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.41 Core Language Keywords vs. Defined Identifiers . . . . . . 19
4.1.42 Instance Naming . . . . . . . . . . . . . . . . . . . . . 19
4.1.43 Length of Identifiers . . . . . . . . . . . . . . . . . . 19
4.1.44 Assign OIDs in the Protocol Mappings . . . . . . . . . . . 20
4.2 Nice-to-Have Objectives . . . . . . . . . . . . . . . . . 20
4.2.1 Methods . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.2 Unions . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.3 Float Data Types . . . . . . . . . . . . . . . . . . . . . 21
4.2.4 Comments . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.5 Referencing Tagged Rows . . . . . . . . . . . . . . . . . 22
4.2.6 Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.7 Internationalization . . . . . . . . . . . . . . . . . . . 23
4.2.8 Separate Data Modelling from Management Protocol Mapping . 23
4.3 Rejected Objectives . . . . . . . . . . . . . . . . . . . 24
4.3.1 Incomplete Translations . . . . . . . . . . . . . . . . . 24
4.3.2 Attribute Value Constraints . . . . . . . . . . . . . . . 24
4.3.3 Attribute Transaction Constraints . . . . . . . . . . . . 25
4.3.4 Method Constraints . . . . . . . . . . . . . . . . . . . . 25
4.3.5 Agent Capabilities . . . . . . . . . . . . . . . . . . . . 25
4.3.6 Relationships . . . . . . . . . . . . . . . . . . . . . . 26
4.3.7 Procedures . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.8 Associations . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.9 Association Cardinalities . . . . . . . . . . . . . . . . 27
4.3.10 Categories of Modules . . . . . . . . . . . . . . . . . . 27
4.3.11 Mapping Modules to Files . . . . . . . . . . . . . . . . . 27
4.3.12 Simple Grammar . . . . . . . . . . . . . . . . . . . . . . 28
4.3.13 Place of Module Information . . . . . . . . . . . . . . . 28
4.3.14 Module Namespace . . . . . . . . . . . . . . . . . . . . . 29
4.3.15 Hyphens in Identifiers . . . . . . . . . . . . . . . . . . 29
5. Security Considerations . . . . . . . . . . . . . . . . . 30
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 30
7. References . . . . . . . . . . . . . . . . . . . . . . . . 30
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 31
9. Full Copyright Statement . . . . . . . . . . . . . . . . . 331. Introduction ✨
This doc lays out the goals for a new data definition language that can be mapped into SNMP [1], [2] and COPS-PR [3] protocol operations. It may also be translated into SMIv2 [4], [5], [6] MIBs and SPPI [7] PIBs. It talks through big ideas like attributes, attribute groups, methods, ways to organize things into reusable data structures, and mechanisms for representing relationships 🦋
2. Motivation 💅
Okay so networking tech has evolved SO much 🔥 Now there's a whole mix of technologies used to manage all the products. Some are Web based, some are standard management protocols, and some are text scripts. The stuff being managed is described in lots of different ways: implicitly in system programming, through proprietary data descriptions, or with standardized descriptions using technologies like MIBs, PIBs, or LDAP schemas 🌈 The result? Management interfaces for network protocols, services, and applications (Differentiated Services included) can look totally different and inconsistent depending on where you're looking 🙈
The SMIng working group got chartered to define a new data definition language that will eliminate the need for a separate SMIv2 and SPPI language. In other words, the new language should cover what the current SMIv2 and SPPI languages need, so that over time we can all just use the new one instead 💖
There's another motivation too: a more expressive and complete way to represent the modeled information ✨ Examples of extra expressiveness and completeness they considered include being able to formally define table existence relationships, expressing instance creation and deletion capabilities, and defining attribute groups using inheritance. These extra features get covered in later sections 🧚
Here's the tea 🍵 The two main goals, (a) merging SMIv2/SPPI and (b) enhancing the state of the art in network management data modeling, can end up in conflict. When that happens, the SMIng working group's consensus is to focus on enhancing the state of the art in network management data modeling 👑
3. Background 🌸
The Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF) looked into creating a protocol-independent data definition language that multiple protocols could use 🔬 Since SMIv2 and SPPI are very similar, the NMRG mostly focused on merging those two languages. They also explored ways to abstract the objectives so the language could work for other protocols too, like LDAP and Diameter. The NMRG published their results in an Internet Draft that has since expired, but they submitted their specification as one proposal to consider while developing the SMIng language 📚
The SMIng Working Group accepted that submission for consideration and used it to better understand the objectives and the possible obstacles to overcome. Where useful, the NMRG proposal gets referenced in the details below 🫶
4. Specific Objectives for SMIng ✨
okay so this is where the actual wishlist lives 💖 these sections list the objectives for a brand new data definition language, sorted into three buckets: accepted objectives (Section 4.1), nice-to-have objectives (Section 4.2), and rejected objectives (Section 4.3). every objective comes with the same little info card:
- Type: tells you what kind of objective it is, using one of these values:
basic: a basic objective for SMIng that is already contained in SMIv2 and/or SPPI.align: supported in different ways in SMIv2 and SPPI, and they need to be aligned.fix: a fix for a known problem in SMIv2 and/or SPPI.new: a new feature.
- From: tells you where the objective came from, and it can have one or more of these values:
SMI: exists in SMIv2.SPPI: exists in SPPI.NMRG: exists in the NMRG proposal, but not in SMIv2 or SPPI.Charter: exists in the working group charter.WG: proposed during working group discussions.
- Description: a quick description of the objective.
- Motivation: the reasoning behind the objective.
- Notes: optional notes about an objective. for nice-to-have or rejected ones, this might explain why the SMIng working group doesn't require the objective, but also why it should still be considered anyway. notes can be opinions from people in the discussion, so they shouldn't be treated as working group consensus or as a recommendation from the objectives editing team 🫶
4.1 Accepted Objectives
this section is the list of objectives the SMIng working group has accepted as worthwhile and deserving of more thought 🌸 each one has to be evaluated by the working group to check that the benefit is worth the cost. an accepted objective can still get rejected later if the cost/benefit analysis says the benefit isn't worth it, or if it clashes directly with one or more other accepted objectives that matter more 💅
4.1.1 The Set of Specification Documents
Type: new
From: NMRG
Description: SMIv2 is defined in three documents, based on an obsolete ITU ASN.1 specification. SPPI is defined in one document, based on SMIv2. the core of SMIng must be defined in one document and must be independent of external specifications.
Motivation: Self-containment.
4.1.2 Textual Representation
Type: basic
From: SMI, SPPI, WG
Description: SMIng definitions must be represented in a textual format.
Motivation: General IETF consensus.
4.1.3 Human Readability
Type: basic
From: WG
Description: the syntax must make it easy for humans to directly read and write SMIng modules. it must be possible for SMIng module authors to produce SMIng modules with text editing tools 📝
Motivation: the syntax must make it easy for humans to read and write SMIng modules.
4.1.4 Rigorously Defined Syntax
Type: new
From: NMRG
Description: there must be a rigorously defined syntax for the SMIng language.
Motivation: an unambiguous language promotes consistency across vendors so that different parsers produce the same results. it also gives module designers authoritative rules to follow ✨
4.1.5 Accessibility
Type: align
From: SMI, SPPI
Description: attribute definitions must indicate whether attributes can be read, written, created, deleted, and whether they are accessible for notifications, or are not accessible. Align PIB-ACCESS and MAX-ACCESS, and PIB-MIN-ACCESS and MIN-ACCESS.
Motivation: alignment of SMIv2 and SPPI.
4.1.6 Language Extensibility
Type: new
From: NMRG
Description: the language must have characteristics so that future modules can contain information using future syntax without breaking original SMIng parsers 🧚
E.g., when SMIv2 introduced REFERENCEs, it would have been nice if it hadn't broken SMIv1 parsers. (the lesson here is the vibe, bestie 😭)
Motivation: achieve language extensibility without breaking core compatibility.
4.1.7 Special Characters in Text
Type: new
From: WG
Description: allow an escaping mechanism to encode special characters, e.g. double quotes and new-line characters, in text such as DESCRIPTIONs or REFERENCEs.
Motivation: ABNF can contain literal characters enclosed in double quotes. to provide the ABNF grammar, there must be the ability to escape special characters.
4.1.8 Naming
Type: basic
From: SMI, SPPI
Description: SMIng must provide mechanisms to uniquely identify attributes, groups of attributes, and events. it is necessary to specify how name collisions are handled.
Motivation: already in SMIv2 and SPPI.
4.1.9 Namespace Control
Type: basic
From: SMI, SPPI
Description: there must be a hierarchical, centrally-controlled namespace for standard named items, and a distributed namespace must be supported to allow vendor-specific naming and to assure unique module names across vendors and organizations.
Motivation: need to unambiguously identify definitions of various kinds. some SMI implementations have problems with different objects from multiple modules that share the same name. furthermore, the probability of module name clashes rises over time (for example, different vendors defining their own SYSTEM-MIB) 🙈
Notes: an example naming scheme is the one used by the Java programming language, with a central naming authority assigning the top-level names.
4.1.10 Modules
Type: basic
From: SMI, SPPI
Description: SMIng must provide a mechanism for uniquely identifying a module, and for specifying the status, contact person, revision information, and purpose of a module.
SMIng must provide mechanisms to group definitions into modules, and it must provide rules for referencing definitions from other modules 📦
Motivation: modularity and independent advancement of documents.
Notes: text about module conformance has been moved to Section 4.1.11.
4.1.11 Module Conformance
Type: basic
From: SMI, SPPI
Description: SMIng must provide mechanisms to detail the minimum requirements implementers must meet to claim conformance to a standard based on the module.
Motivation: ability to convey conformance requirements.
4.1.12 Arbitrary Unambiguous Identities
Type: basic
From: SMI
Description: SMI allows the use of OBJECT-IDENTITIES to define unambiguous identities without the need for a central registry. SMI uses OIDs to represent values that refer to such identities. SMIng needs a similar mechanism (a statement to register identities, and a base type to represent values).
Motivation: SMI compatibility.
Notes: this is an obvious objective. additionally, everything not on the wire, such as modules, will still be assigned OIDs.
it is yet to be determined whether the assignment of the OID occurs within the core or within a protocol-specific mapping 🤔
4.1.13 Protocol Independence
Type: basic
From: Charter
Description: SMIng must define data definitions in support of the SNMP and COPS-PR protocols. SMIng may define data definitions in support of other protocols.
Motivation: so data definitions can be used with multiple protocols and multiple versions of those protocols. 🦋
4.1.14 Protocol Mapping
Type: basic
From: Charter
Description: the SMIng working group, in accordance with the working group charter, will define mappings of protocol-independent data definitions to protocols based upon installed implementations. the SMIng working group can define mappings to other protocols as long as this does not impede progress on other objectives.
Motivation: SMIng working group charter.
4.1.15 Translation to Other Data Definition Languages
Type: basic
From: Charter
Description: SMIng language constructs must, wherever possible, be translatable to SMIv2 and SPPI. at the time of standardization of a SMIng language, existing SMIv2 MIBs and SPPI PIBs on the standards track will not be required to be translated to the SMIng language. new MIBs/PIBs will be defined using the SMIng language.
Motivation: provide best-effort backwards compatibility for existing tools without placing an unnecessary burden on MIBs/PIBs that are already on the standards track 🫶
4.1.16 Base Data Types
Type: basic
From: SMI, SPPI
Description: SMIng must support the base data types Integer32, Unsigned32, Integer64, Unsigned64, Enumeration, Bits, OctetString, and OID.
Motivation: most are already common. Unsigned64 and Integer64 are in SPPI and must be fixed in SMI. note that the Counter and Gauge types can be regarded as derived types instead of base types.
4.1.17 Enumerations
Type: basic
From: SMI, SPPI
Description: SMIng must provide support for enumerations. enumerated values must be a part of the enumeration definition.
Motivation: SMIv2 already has enumerated numbers.
Notes: enumerations have the implicit constraint that the attribute is constrained to the values of the enumeration.
4.1.18 Discriminated Unions
Type: new
From: WG
Description: SMIng must support discriminated unions.
Motivation: allows related attributes to be grouped together, such as InetAddressType (discriminator) and InetAddress, InetAddressIPv4, InetAddressIPv6 (union). the lack of discriminated unions has also led to relatively complex sparse table workarounds in some DISMAN mid-level manager MIBs 🌈
Notes: discriminated unions have the property that the union attribute type is constrained by the value of the discriminator attribute.
4.1.19 Instance Pointers
Type: basic
From: SMI, SPPI
Description: SMIng must allow specifying pointers to instances (i.e., a pointer to a particular attribute in a row).
Motivation: it is common practice in MIBs and PIBs to point to other instances.
4.1.20 Row Pointers
Type: align
From: SMI, SPPI
Description: SMIng must allow specifying pointers to rows.
Motivation: it is common practice in MIBs and PIBs to point to other rows (see RowPointer, PIB-REFERENCES). 👑
4.1.21 Constraints on Pointers
Type: align
From: SPPI
Description: SMIng must allow specifying the types of objects to which a pointer may point.
Motivation: this allows code generators to detect and reject illegal pointers automatically. it can also be used to automatically generate more reasonable implementation-specific data structures.
Notes: pointer constraints are a special case of attribute value constraints (Section 4.3.2), in which the prefix of the OID (row or instance pointer) value is limited to come only from a particular table.
4.1.22 Base Type Set
Type: basic
From: SMI, SPPI
Description: SMIng must support a fixed set of base types of fixed size and precision. the list of base types must not be extensible unless the SMI itself changes. 🔒
Motivation: interoperability.
4.1.23 Extended Data Types ✨
Type: align
From: SMI, SPPI
Description: okay so SMIng has to have a way to make new types that come with extra meaning (think Counters, Gauges, Strings, etc.) by building them off of base types 💅 It can also be nice to make new types out of types you already derived, bestie. 🧚 The rule is that any new type has to be just as restrictive or MORE restrictive than the types it's specializing. no loosening up allowed 🔒
Motivation: SMI uses application types and textual conventions. SPPI uses derived types. Two different vibes, same goal 🫶
4.1.24 Units, Formats, and Default Values of Defined Types and Attributes
Type: fix
From: NMRG
Description: so in SMIv2, OBJECT-TYPE definitions can have UNITS and DEFVAL clauses, and TEXTUAL-CONVENTIONs can have DISPLAY-HINTs 🎀 The glow-up idea is that units and default values should also work on defined types, and format info should work on attributes too ✨
Motivation: some MIBs make TCs like KBytes, and then every single usage of that TC has to say the UNITS "KBytes" again. ngl that's a lot of repeating 😭 It would be way simpler if the units lived right on the type definition itself 💖
Notes: the SMIng WG has to clarify what happens if an attribute uses a defined type and BOTH the attribute and the defined type have units/default/format info. this one's a plot twist that needs figuring out 🍓
4.1.25 Table Existence Relationships
Type: align
From: SMI, SPPI
Description: SMIng must support INDEX, AUGMENTS, and EXTENDS in the SNMP/COPS-PR protocol mappings 🌸
Motivation: these three table existence relationships already show up in either SMIv2 or SPPI, so they're a must-have 🦋
4.1.26 Table Existence Relationships (2)
Type: new
From: NMRG
Description: SMIng must support EXPANDS and REORDERS relationships in the SNMP/COPS-PR protocol mappings 🧚
Motivation: a REORDERS statement lets you swap up the indexing order 🔄 and an EXPANDS statement formally says there's a 1:n existence relationship between table rows. it's giving precision 💅
4.1.27 Attribute Groups
Type: new
From: NMRG
Description: an attribute group is a named, reusable set of attributes that belong together 🎀 It can be reused as the type of attributes in other attribute groups (see also Section 4.1.28). kinda like structs in C, iykyk 🫶
Motivation: needed so the same grouping of attributes can get mapped into both SNMP and COPS-PR tables. it also lets you reorder indexes without redefining the whole attribute group 🙌 and grouping related attributes together (e.g. InetAddressType, InetAddress) is so iconic 👑
The ability to group attributes gives a little signal that the attributes are meaningful together 💜
4.1.28 Containment
Type: new
From: NMRG
Description: SMIng must provide support for creating new attribute groups out of attributes of more basic types and, potentially, other attribute groups 🧩
Motivation: this makes it easier to reuse attribute groups like the InetAddressType and InetAddress pairs. no more copy-pasting 🙈
Notes: containment comes with an implicit existence constraint: if an instance of a contained attribute group exists, then the matching instance of the containing attribute group has to exist too 🫧
4.1.29 Single Inheritance
Type: new
From: NMRG
Description: SMIng must provide support for mechanisms that extend attribute groups through single inheritance 🌈
Motivation: lets you extend attribute groups (like a generic DiffServ scheduler) with attributes for one specific scheduler, all without the cut&paste ✂️ bestie no duplicate code
Notes: single inheritance with multiple levels (e.g., C derives from B, and B derives from A) must be allowed. slay 👑
Inheritance also comes with an implicit existence constraint: if an instance of a derived attribute group exists, then the matching instance of the base attribute group has to exist too 💖
Inheritance could also help add attributes to an attribute group that are specific to a certain protocol mapping and don't show up in the protocol-neutral attribute group. very useful, very sneaky 🦋
4.1.30 Reusable vs. Final Attribute Groups
Type: new
From: NMRG, WG
Description: SMIng must tell the difference between "final" and reusable attribute groups, where reuse covers both inheritance and containment 🎀
Motivation: this gives people more info about how attribute groups can and should get used, and it stops them from misusing them. guardrails, but make it cute 💅
Notes: this objective is basically saying that some attribute groups aren't meant to stand alone. they only make sense when they're contained inside another attribute group 🧸
4.1.31 Events
Type: basic
From: SMI, SPPI
Description: SMIng must provide mechanisms to define events that flag significant state changes ⚡
Motivation: these are the protocol-independent events that lead to SMI notifications or SPPI reports. the main characters of the whole thing 🎬
4.1.32 Creation/Deletion
Type: align
From: SMI, SPPI
Description: SMIng must support a mechanism to define creation/deletion operations for instances. specific creation/deletion errors, like INSTALL-ERRORS, must be supported too 🌷
Motivation: this already exists for row creation in SMI, and it's available in SPPI 🙌
4.1.33 Range and Size Constraints
Type: basic
From: SMI, SPPI
Description: SMIng must allow specifying range and size constraints where they apply 📏
Motivation: both SMI and SPPI already support range and size constraints. easy win 💅
4.1.34 Uniqueness
Type: basic
From: SPPI
Description: SMIng must allow uniqueness constraints to be specified on attributes. SMIng must also allow multiple independent uniqueness constraints 🔑
Motivation: knowing the uniqueness constraints on attributes lets you check protocol-specific mappings (e.g. INDEX clauses) 🧐 and code generators can use that info to make their generated implementation-specific data structures better 🚀
4.1.35 Extension Rules
Type: basic
From: SMI, SPPI
Description: SMIng must provide clear rules for how to extend SMIng modules without causing interoperability problems "over the wire" 📡
Motivation: SMIv2 and SPPI both already have extension rules, so this is a classic 🎞️
4.1.36 Deprecate Use of IMPLIED Keyword
Type: fix
From: WG
Description: the SMIng SNMP mapping must deprecate the use of the IMPLIED indexing scheme 🚫
Motivation: IMPLIED is confusing and most people don't understand it 😵💫 the fix (IMPLIED) is honestly worse than the problem it's trying to solve, so for the sake of simplicity, the use of IMPLIED should be deprecated. periodt 💀
4.1.37 No Redundancy
Type: fix
From: NMRG
Description: the SMIng language must avoid redundancy 🧹
Motivation: remove any textual redundancy for stuff like table entries and SEQUENCE definitions, since that just makes specs longer without adding any value 🙄
4.1.38 Compliance and Conformance
Type: basic
From: SMI, SPPI
Description: SMIng must provide a mechanism for compliance and conformance specifications, both for protocol-independent definitions and for protocol mappings 📋
Motivation: this capability exists in SMIv2 and SPPI already 💅 the NMRG proposal can express a lot of this info at the protocol-dependent layer. some compliance or conformance info might be protocol-independent though, so there's also a need to express that protocol-independent part too 🫶
4.1.39 Allow Refinement of All Definitions in Conformance Statements
Type: fix
From: WG
Description: okay so SMIv2, RFC 2580, Section 3.1 says:
The OBJECTS clause, which must be present, is used to specify
each object contained in the conformance group. Each of the
specified objects must be defined in the same information
module as the OBJECT-GROUP macro appears, and must have a MAX-
ACCESS clause value of "accessible-for-notify", "read-only",
"read-write", or "read-create".The last sentence forbids putting a not-accessible INDEX object into an OBJECT-GROUP 🚫 which means you can't refine its syntax in a compliance definition. the drama 😭 For more details, see http://www.ibr.cs.tu-bs.de/ietf/smi-errata/
Motivation: this error should not be repeated in SMIng 🙅♀️
4.1.40 Categories
Type: basic
From: SPPI
Description: SMIng must provide a mechanism for grouping definitions into subject categories. concrete instances may only exist inside the scope of a given subject category or context 🗂️
Motivation: this is to scope which categories a module applies to. in SPPI it lets different client types split up the work 🤝
4.1.41 Core Language Keywords vs. Defined Identifiers
Type: fix
From: NMRG
Description: in SMI and SPPI modules, some language keywords (macros and a number of basetypes) have to be imported from different SMI language defining modules. for example, OBJECT-TYPE, MODULE-IDENTITY, and Integer32 must be imported from SNMPv2-SMI, and TEXTUAL-CONVENTION must be imported from SNMPv2-TC, if used. MIB authors are constantly confused by these import rules 😩 In SMIng, only defined identifiers must be imported. all SMIng language keywords must be implicitly known, so there's no need to import them from any module ✨
Motivation: reduce confusion and clarify the set of language keywords 💜
4.1.42 Instance Naming
Type: align
From: SMI, SPPI
Description: instance naming in SMIv2 and SPPI is different. SMIng must align instance naming (either in the protocol-neutral model or in the protocol mappings) 🔁
Motivation: COPS-PR and SNMP have different instance identification schemes that have to be handled 🧩
Notes: a solution means checking how close the naming schemes dictated by the protocols are. maybe it's possible to have a single instance naming scheme for both SNMP and COPS-PR, even though current SPPI and SMIv2 are different 🤞
4.1.43 Length of Identifiers
Type: fix
From: NMRG
Description: the allowed length of the various kinds of identifiers must be extended from the current should not exceed 32 (maybe even from the must not exceed 64) rule 📏
Motivation: reflects current practice for definitions 📖
Notes: the 32-rule was added back when compilers couldn't handle long identifiers. this rule gets violated constantly these days, so it doesn't make sense to keep it 🙃
4.1.44 Assign OIDs in the Protocol Mappings
Type: new
From: NMRG
Description: SMIng must not assign OIDs to reusable definitions of attributes, attribute groups, events, etc. instead, the SNMP and COPS-PR mappings must assign OIDs to the mapped items 🔢
Motivation: assigning OIDs in protocol-neutral definitions can complicate reuse. OIDs of synonymous attributes are not the same in SMI and SPPI definitions. MIBs and PIBs are already registered in different parts of the OID namespace, so it's already a whole thing 🌍
4.2 Nice-to-Have Objectives 💫
This section is the list of recommended objectives that would be nice to have 🎀 However, these aren't automatically treated as accepted objectives. for example, they may need a lot of work in underlying protocols to support, or they may be considered less important than other conflicting objectives that have been accepted 🫶
4.2.1 Methods ✨
Type: new
From: WG
okay bestie, the ask here is that SMIng should support a way to define method signatures (parameters, return values, and exceptions) that get implemented on agents 🔧
Why do we even need this? Methods are needed for operational interfaces like the ones in [RFC2925] (ping, traceroute, and lookup operations) 🏓. Also, being able to define constructor/destructor interfaces could fix stuff like the mess people ran into with SNMP's RowStatus solution 😭
The notes are where it gets spicy 🌶️ Is it possible to do methods without changing the underlying protocol? Everyone agrees methods are useful, but nobody agrees on the impact. One side sees it as a documentation tool for the SNMP stuff we already have, and the other side sees it as a protocol update that natively supports methods going forward. The proposal is to wait and see if it's practical to implement as a syntax that's actually useful and can map to the protocol 🤞
4.2.2 Unions 🎀
Type: new
From: WG
the vibe is that SMIng should support a standard format for unions 💅
Motivation: a union lets an attribute hold one of many types of values 🫶 The lack of unions has also led to relatively complex sparse table work-arounds in some DISMAN mid-level managers 🙈 Apart from discriminated unions (see Section 4.1.18), this kind of union has no accompanying explicit discriminator attribute that selects the union's type of value.
Notes: the thought is that SNMP and COPS-PR can already support unions because they don't care what data type goes with a particular OID 🧠
4.2.3 Float Data Types 🦋
Type: new
From: WG, NMRG
so SMIng should support the base data types Float32, Float64, and Float128 🔥
Motivation: missing base types can hurt later, because you can't add them without changing the language, even as an SMIng extension 💀 This is a lesson learned from the SMIv1/v2 debate about Counter64/Integer64/... 📚
Notes: there's no mention of whether the underlying protocols will have to natively support float data types. That's left to the mapping 🗺️ However, it seems imperative that the float data type gets added to the set of intrinsic types in the SMIng language when the language is created, because it'll be impossible to add them later without changing the language 😤
4.2.4 Comments 💬
Type: fix
From: NMRG
the goal is that the syntax of comments should be well defined, unambiguous, and intuitive to most people, e.g., the C++/Java // syntax ✨
Motivation: ASN.1 comments (and therefore SMI and SPPI comments) have been a constant source of confusion 🥲 People use arbitrary lengthy strings of dashes (-----------) thinking that's always treated as a comment, and some implementations try to accept these syntactically wrong constructs, which just makes it more confusing. We should get rid of this problem 🙅♀️
Notes: if the SMIng working group adopts a C-like syntax, then the C++/Java single-line comment should be adopted as well 🌸
4.2.5 Referencing Tagged Rows 🏷️
Type: align
From: SPPI
PIB and MIB row attributes reference a group of entries in another table. SPPI formalizes this by introducing PIB-TAG and PIB-REFERENCES clauses 📋 This functionality should be retained in SMIng 🫶
Motivation: SPPI formalizes tag references. Some MIBs also use tag references (see SNMP-TARGET-MIB in RFC2573) even though SMIv2 doesn't provide a formal notation 🧚
4.2.6 Arrays 🌈
Type: new
From: WG
SMIng should allow the definition of a SEQUENCE OF attributes or attribute groups (Section 4.1.27) 🍓
Motivation: people want the ability to have variable-length, multi-valued objects 💜
Notes: some issues with arrays are still unclear 🥴 As long as there are no concepts to solve the problems with access semantics (how to achieve atomic access to arbitrary-sized arrays) and their mappings to SNMP and COPS-PR protocol operations, arrays can't be more than a nice-to-have objective 🌷
4.2.7 Internationalization 🌍
Type: new
From: WG
informational text (DESCRIPTION, REFERENCE, ...) should allow i18nized encoding, probably UTF-8 🫶
Motivation: there's been some demand for i18n in the past, and BCP RFC 2277 demands internationalization 👑
Notes: although English is the language of IETF documents, SMIng should allow other languages for private use 🌸
4.2.8 Separate Data Modelling from Management Protocol Mapping 🧩
Type: new
From: NMRG
it should be possible to separate the domain-specific data modelling work from the network management protocol specific work 🦋
Motivation: today, working groups designing new protocols are forced to care about the design of SNMP MIBs and maybe COPR-PR PIBs to manage the new protocol 😩 That means experts in a specific domain are faced with the details of at least one foreign (network management) technology. This leads to hard work and long revision processes. It would be a win to separate the task of pure data modelling, which domain experts can do easily, from the network management protocol specific mappings. The mapping to SNMP and/or COPS-PR can be done (a) later, separately, and (b) by network management experts. This means the NM expertise required no longer hinders the progress of the domain-specific working groups 🙌
4.3 Rejected Objectives 🚫
This section is the list of objectives that were rejected during the discussion on the objectives 📝 Objectives that have been rejected don't need to be addressed by SMIng. This does not imply that they must not be addressed 🤷♀️
4.3.1 Incomplete Translations 🥀
Type: basic
From: WG
ngl, reality sucks 😭 All information expressed in SMIng may not be directly translatable to a MIB or PIB construct, but all information should be able to be conveyed in documentation or via other mechanisms 📖
Motivation: the SMIng working group requires this to ease the transition ✨
Notes: the SMIng language itself can't require what compilers do when they translate SMIng into something else. So this seems to fall out of the scope of the current working group charter 🫠
4.3.2 Attribute Value Constraints ⛓️
Type: new
From: WG
SMIng should provide mechanisms to formally specify constraints between values of multiple attributes 📐
Motivation: constraints on attribute values happen where one or more attributes may affect the value or range of values for another attribute. One such relationship exists in IPsec, where the type of security algorithm determines the range of possible values for other attributes, such as the corresponding key size 🔐
Notes: this objective as it is has been rejected as too general, and therefore virtually impossible to implement 💀 However, constraints that are implicit with discriminated unions (Section 4.1.18), enumerated types (Section 4.1.17), pointer constraints (Section 4.1.21)), etc., are accepted, and these implicit constraints are mentioned in the respective objectives ✅
4.3.3 Attribute Transaction Constraints 🔒
Type: new
From: WG
SMIng should provide a mechanism to formally express that certain sets of attributes can only be modified in combination 🫶
Motivation: COPS-PR always does operations on table rows in a single transaction. There are SMIv2 attribute combinations that need to be modified together (such as InetAddressType, InetAddress) 🧵
Notes: the alternative is to either use Methods (Section 4.2.1) or assume that all attributes in an attribute group (Section 4.1.27) are to be considered atomic 🤓
4.3.4 Method Constraints 🎯
Type: new
From: WG
method definitions should provide constraints on parameters 🫤
Motivation: None.
Notes: unless methods (Section 4.2.1) are done, there's no use for this. Furthermore, this objective hasn't been motivated by any proponent 🙃
4.3.5 Agent Capabilities 🤖
Type: basic
From: SMI
SMIng should provide mechanisms to describe agent implementations 🪞
Motivation: to permit a manager to determine variations from the standard for an implementation 👀
Notes: agent capabilities shouldn't be part of SMIng. They should instead be a separate capabilities table 📊
4.3.6 Relationships 💞
Type: new
From: NMRG, WG
the ability to formally depict existence dependency, value dependency, aggregation, containment, and other relationships between attributes or attribute groups 🕸️
Motivation: it helps humans understand the conceptual model of a module, and helps implementers of MIB compilers generate more 'intelligent' code 🧠
Notes: this objective was deemed too general to be useful. Instead, the individual types of relationship objectives (e.g., pointers, inheritance, containment, etc.) are evaluated on a case-by-case basis, with the specific relationships deemed useful being included as accepted objectives 🗂️
4.3.7 Procedures 📜
Type: new
From: WG
SMIng should support a mechanism to formally define procedures that are used by managers when interacting with an agent 🤝
Motivation: None.
Notes: this objective hasn't been motivated by any proponent 😶
4.3.8 Associations 🔗
Type: new
From: WG
SMIng should provide mechanisms to explicitly specify associations 💫
Motivation: None.
Notes: this objective hasn't been motivated by any proponent 🥱
4.3.9 Association Cardinalities 🔢
Type: new
From: WG
cardinalities between associations should be formally defined 📏
Motivation: if you have an association between attribute groups A and B, the cardinality of A indicates how many instances of A may be associated with a single instance of B. Our discussions in Minneapolis indicated that we want to convey "how many" instances are associated in order to define the best mapping algorithm, whether that's a new table, a single pointer, etc. For example, do we use RowPointer or an integer index into another table? Do we map to a table that holds instances of the association/relationship itself? 🤔
Notes: without associations (Section 4.3.8), this has no use 🫠
4.3.10 Categories of Modules 🗃️
Type: new
From: WG
the SMIng documents should give clear guidance on which kind of information (with respect to generality, type/attribute group/extension/..) should be put in which kind of module 📚
E.g., in SMIv2 we don't like to import Utf8String from SYSAPPL-MIB, but we also don't like to introduce a redundant definition 😤
A module review process should probably be described that ensures that generally useful definitions don't go into device or service specific modules 🛡️
Motivation: bad experience with SMIv2 💀
Notes: it's not clear how this can be done with the language to be created by the SMIng WG 🥹
4.3.11 Mapping Modules to Files ✨
- Type: new
- From: NMRG
- Description: okay so there should be a clear statement about how SMIng modules get mapped to files (
1:1, n:1?), and how those files should be named (by module name if it's a1:1mapping?) 📁 - Motivation: SMI implementations use a whole mess of filename extensions (
.txt,.smi,.my, or none at all) 😭 Some expect every module in one single file, and others don't. That makes exchanging modules way harder than it needs to be. - Notes: this is really just an implementation detail, so it's best left to a BCP and not made part of the language definition 🙈
4.3.12 Simple Grammar 💅
- Type: new
- From: NMRG
- Description: the grammar of the language should be as simple as possible. It should be free of exception rules. The way we measure simplicity is by how short the ABNF grammar is 📏
- Motivation: ease of implementation, and ease of learning and understanding 🧠
- Notes: this seems like a super obvious objective, but a short ABNF grammar isn't necessarily a sign of a simple grammar. Plot twist 👀
4.3.13 Place of Module Information 🎀
- Type: fix
- From: NMRG
- Description: module-specific information (organization, contact, description, revision information) should be bound to the module itself, and not to an artificial node (like SMIv2 MODULE-IDENTITY) 🧁
- Motivation: simplicity and design cleanup ✨
- Notes: this doesn't seem to be a problem with the current SMI. Simplification is a good thing, but this particular detail isn't considered an objective 🤷♀️
4.3.14 Module Namespace 🌸
- Type: new
- From: WG
- Description: right now the namespace of modules is flat, with no structure in module naming, which creates a potential risk of name clashes 😬 Possible solutions:
- Assume module names are globally unique (just as SMIv1/v2 do), and just give some recommendations on module names.
- Force all organizations, WGs and vendors to apply a name prefix (e.g.
CISCO-GAGA-MIB,IETF-DISMAN-SCRIPT-MIB?). - Force enterprises to apply a prefix based on the enterprise number (e.g.
ENT2021-SOME-MIB). - Put module names in a hierarchical domain-based namespace (e.g.
DISMAN-SCRIPT-MIB.ietf.org).
- Motivation: reduce the risk of module name clashes 🫶
- Notes: some parts of this objective overlap with other objectives (namespace control (Section 4.1.9)), and other parts were thought best left to a BCP 💜
4.3.15 Hyphens in Identifiers 🦋
- Type: fix
- From: NMRG
- Description: okay so there's been some confusion about whether hyphens are allowed in SMIv2 identifiers 🙃 Module names are allowed to contain hyphens. Node identifiers usually aren't. But `mib-2' is a super frequently used identifier that contains a hyphen anyway, because of its SMIv1 origin, back when hyphens weren't disallowed. Similarly, a bunch of named numbers of enumeration types contain hyphens, which breaks an SMIv2 rule.
SMIng should simply allow hyphens in all kinds of identifiers. No exceptions. 💖
- Motivation: reduce confusion and exceptions. This does, however, require that implementation mappings properly quote hyphens where appropriate 🎀
- Notes: this nit-picking isn't really worth being subject to the discussion on objectives. However, SMIng should care that compilers have to map SMIng to programming languages where a hyphen is a minus, and so isn't allowed in identifiers 🔥
5. Security Considerations 🔐
This document defines objectives for a language with which to write and read descriptions of management information. The language itself has no security impact on the Internet. Phew, no drama here 💅✨
6. Acknowledgements 🫶
Thanks to Dave Durham, whose work on the original NIM (Network Information Model) draft was used in generating this document 🌷
Thanks to Andrea Westerinen for her contributions on the original NIM requirements and SMIng objectives drafts 💜
7. References 📚
[1] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990.
[2] McCloghrie, K., Case, J., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
[3] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R. and A. Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001.
[4] 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.
[5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[6] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[7] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, S., Sahita, R., Smith, A. and F. Reichmeyer, "Structure of Policy Provisioning Information (SPPI)", RFC 3159, August 2001.
8. Authors' Addresses 💌
Chris Elliott
Cisco Systems
7025 Kit Creek Road
Research Triangle Park, NC 27709
USA
EMail: chelliot@cisco.com
David Harrington
Enterasys Networks
35 Industrial Way
P.O. Box 5005
Rochester, NH 03866-5005
USA
EMail: dbh@enterasys.com
Jamie Jason
Intel Corporation
MS JF3-206
2111 NE 25th Ave.
Hillsboro, OR 97124
USA
EMail: jamie.jason@intel.com
Juergen Schoenwaelder
TU Braunschweig
Muehlenpfordtstr. 23
38106 Braunschweig
Germany
EMail: schoenw@ibr.cs.tu-bs.de
URI: http://www.ibr.cs.tu-bs.de/
Frank Strauss
TU Braunschweig
Muehlenpfordtstr. 23
38106 Braunschweig
Germany
EMail: strauss@ibr.cs.tu-bs.de
URI: http://www.ibr.cs.tu-bs.de/
Walter Weiss
Ellacoya Networks
7 Henry Clay Dr.
Merrimack, NH. 03054
USA
EMail: wweiss@ellacoya.com9. Full Copyright Statement ©️
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
Acknowledgement 💜
Funding for the RFC Editor function is currently provided by the Internet Society. 🌈
📦 where this page comes from
- ietf: rfc3216 2001-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms