As per Relevance of the word objective, we have this rfc below:
Network Working Group C.
Request for Comments: 3216 Cisco
Category: Informational D.
Enterasys
J.
Intel
J.
F.
TU
W.
Ellacoya
December 2001
SMIng
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document describes the objectives for a new data
language, suitable for the modeling of network management constructs
that can be directly mapped into SNMP and COPS-PR
operations
The purpose of this document is to serve as a set of objectives
a subsequent language specification should try to address.
captures the results of the working group discussions
consensus on the SMIng objectives
Table of
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
Elliott, et al. Informational [Page 1]
RFC 3216 SMIng Objectives December 2001
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
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
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
Elliott, et al. Informational [Page 2]
RFC 3216 SMIng Objectives December 2001
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 . . . . . . . . . . . . . . . . . 33
1.
This document describes the objectives for a new data
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. Concepts such as attributes,
groups, methods, conventions for organization into reusable
structures, and mechanisms for representing relationships
discussed
2.
As networking technology has evolved, a diverse set of
has been deployed to manage the resulting products. These vary
Web based products, to standard management protocols and
scripts. The underlying systems to be manipulated are represented
varying ways including implicitly in the system programming,
proprietary data descriptions, or with standardized
using a range of technologies including MIBs, PIBs, or LDAP schemas
The result is that management interfaces for network protocols
services, and applications such as Differentiated Services may
represented in many different, inconsistent fashions
Elliott, et al. Informational [Page 3]
RFC 3216 SMIng Objectives December 2001
The SMIng working group has been chartered to define a new
definition language that will eliminate the need for a separate SMIv
and SPPI language. That is, the new language should address
needs for the current SMIv2 and SPPI languages so that over time
can all use the new language instead
Another motivation is to permit a more expressive and
representation of the modeled information. Examples of
expressiveness and completeness that are considered are the
to formally define table existence relationships, the expression
instance creation/deletion capabilities, and the ability to
attribute groups using inheritance. These additional features
discussed in subsequent sections
It has been recognized that the two main goals of (a)
SMIv2/SPPI and (b) enhancing the state of art in network
data modeling can lead to conflicts. In such cases, the
working group's consensus is to focus on enhancing the state of
in network management data modeling
3.
The Network Management Research Group (NMRG) of the Internet
Task Force (IRTF) has researched the issues of creating a protocol
independent data definition language that could be used by
protocols. Because SMIv2 and SPPI are very similar, the NMRG
on merging these two languages, but also researched ways to
the objectives to produce a language that could be used for
protocols, such as LDAP and Diameter. The NMRG has published
results of their work in a meanwhile expired Internet Draft, but
submitted their specification as one proposal to consider in
development of the SMIng language
The SMIng Working Group has accepted their submission
consideration, and to use their proposal to better understand
objectives and possible obstacles to be overcome. Where useful,
NMRG proposal has been referenced in the details below
4. Specific Objectives for
The following sections define the objectives for the definition of
new data definition language. The objectives have been organized
follows: accepted objectives (Section 4.1), nice-to-have
(Section 4.2), and rejected objectives (Section 4.3). Each
has the following information
o Type: a field that identifies the type of objective, using one
the following values
Elliott, et al. Informational [Page 4]
RFC 3216 SMIng Objectives December 2001
* basic: considered a basic objective for SMIng and is
in SMIv2 and/or SPPI
* align: supported in different ways in SMIv2 and SPPI and
must be aligned
* fix: considered a fix for a known problem in SMIv2 and/or SPPI
* new: considered a new feature
o From: a field that defines the origin of the objective and
contains one or more of the following values
* SMI: exists in SMIv2.
* SPPI: exists in SPPI
* NMRG: exists in the NMRG proposal, but not in SMIv2 or SPPI
* Charter: exists in working group charter
* WG: proposed during working group discussions
o Description: a quick description of the objective
o Motivation: rationale for the objective
o Notes: optional notes about an objective. For example, for nice
to-have or rejected this may contain reasoning why this
is not required by the SMIng working group, but justification
it should be considered anyway. Notes may be the opinions of
participants in the discussion on objectives and as such
not be taken as consensus of the working group or
recommendation of the objectives editing team
4.1 Accepted
This section represents the list of objectives that have
accepted by the SMIng working group as worthwhile and
deserving of further consideration. Each of these objectives must
evaluated by the working group to determine if the benefit incurs
acceptable level of cost. An accepted objective may subsequently
rejected if the cost/benefit analysis determines that the
does not justify the cost or that the objective is in direct
with one or more other accepted objectives that are deemed
important
Elliott, et al. Informational [Page 5]
RFC 3216 SMIng Objectives December 2001
4.1.1 The Set of Specification
Type:
From:
Description: SMIv2 is defined in three documents, based on
obsolete ITU ASN.1 specification. SPPI is defined in
document, based on SMIv2. The core of SMIng must be defined
one document and must be independent of external specifications
Motivation: Self-containment
4.1.2 Textual
Type:
From: SMI, SPPI,
Description: SMIng definitions must be represented in a
format
Motivation: General IETF consensus
4.1.3 Human
Type:
From:
Description: The syntax must make it easy for humans to directly
and write SMIng modules. It must be possible for SMIng
authors to produce SMIng modules with text editing tools
Motivation: The syntax must make it easy for humans to read and
SMIng modules
4.1.4 Rigorously Defined
Type:
From:
Description: There must be a rigorously defined syntax for the
language
Elliott, et al. Informational [Page 6]
RFC 3216 SMIng Objectives December 2001
Motivation: An unambiguous language promotes consistency
vendors so that different parsers produce the same results.
also provides authoritative rules to SMIng modules designers
4.1.5
Type:
From: SMI,
Description: Attribute definitions must indicate whether
can be read, written, created, deleted, and whether they
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
Type:
From:
Description: The language must have characteristics, so that
modules can contain information of future syntax without
original SMIng parsers
E.g., when SMIv2 introduced REFERENCEs it would have been nice
it would not have broken SMIv1 parsers
Motivation: Achieve language extensibility without breaking
compatibility
4.1.7 Special Characters in
Type:
From:
Description: Allow an escaping mechanism to encode
characters, e.g. double quotes and new-line characters, in
such as DESCRIPTIONs or REFERENCEs
Motivation: ABNF can contain literal characters enclosed in
quotes; to provide the ABNF grammar, there must be the ability
escape special characters
Elliott, et al. Informational [Page 7]
RFC 3216 SMIng Objectives December 2001
4.1.8
Type:
From: SMI,
Description: SMIng must provide mechanisms to uniquely
attributes, groups of attributes, and events. It is necessary
specify how name collisions are handled
Motivation: Already in SMIv2 and SPPI
4.1.9 Namespace
Type:
From: SMI,
Description: There must be a hierarchical, centrally-
namespace for standard named items, and a distributed
must be supported to allow vendor-specific naming and to
unique module names across vendors and organizations
Motivation: Need to unambiguously identify definitions of
kinds. Some SMI implementations have problems with
objects from multiple modules but with the same name
Furthermore, the probability of module name clashes rises
time (for example, different vendors defining their own SYSTEM
MIB).
Notes: An example naming scheme is the one employed by the
programming language with a central naming authority assigning
top-level names
4.1.10
Type:
From: SMI,
Description: SMIng must provide a mechanism for uniquely
a module, and specifying the status, contact person,
information, and the purpose of a module
SMIng must provide mechanisms to group definitions into
and it must provide rules for referencing definitions from
modules
Elliott, et al. Informational [Page 8]
RFC 3216 SMIng Objectives December 2001
Motivation: Modularity and independent advancement of documents
Notes: Text about module conformance has been moved to
4.1.11.
4.1.11 Module
Type:
From: SMI,
Description: SMIng must provide mechanisms to detail the
requirements implementers must meet to claim conformance to
standard based on the module
Motivation: Ability to convey conformance requirements
4.1.12 Arbitrary Unambiguous
Type:
From:
Description: SMI allows the use of OBJECT-IDENTITIES to
unambiguous identities without the need of a central registry
SMI uses OIDs to represent values that represent references
such identities. SMIng needs a similar mechanism (a statement
register identities, and a base type to represent values).
Motivation: SMI Compatibility
Notes: This is an obvious objective. Additionally, everything not
the wire, such as modules, will still be assigned OIDs
It is yet to be determined whether the assignment of the
occurs within the core or within a protocol-specific mapping
4.1.13 Protocol
Type:
From:
Description: SMIng must define data definitions in support of
SNMP and COPS-PR protocols. SMIng may define data definitions
support of other protocols
Elliott, et al. Informational [Page 9]
RFC 3216 SMIng Objectives December 2001
Motivation: So data definitions may be used with multiple
and multiple versions of those protocols
4.1.14 Protocol
Type:
From:
Description: The SMIng working group, in accordance with the
group charter, will define mappings of protocol independent
definitions to protocols based upon installed implementations
The SMIng working group can define mappings to other protocols
long as this does not impede the progress on other objectives
Motivation: SMIng working group charter
4.1.15 Translation to Other Data Definition
Type:
From:
Description: SMIng language constructs must, wherever possible,
translatable to SMIv2 and SPPI. At the time of standardization
a SMIng language, existing SMIv2 MIBs and SPPI PIBs on
standards track will not be required to be translated to the
language. New MIBs/PIBs will be defined using the SMIng language
Motivation: Provide best-effort backwards compatibility for
tools while not placing an unnecessary burden on MIBs/PIBs
are already on the standards track
4.1.16 Base Data
Type:
From: SMI,
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
SPPI, must fix in SMI. Note that Counter and Gauge types can
regarded as derived types instead of base types
Elliott, et al. Informational [Page 10]
RFC 3216 SMIng Objectives December 2001
4.1.17
Type:
From: SMI,
Description: SMIng must provide support for enumerations.
values must be a part of the enumeration definition
Motivation: SMIv2 already has enumerated numbers
Notes: Enumerations have the implicit constraint that the
is constrained to the values for the enumeration
4.1.18 Discriminated
Type:
From:
Description: SMIng must support discriminated unions
Motivation: Allows to group related attributes together, such
InetAddressType (discriminator) and InetAddress, InetAddressIPv4,
InetAddressIPv6 (union). The lack of discriminated unions
also lead to relatively complex sparse table work-around in
DISMAN mid-level manager MIBs
Notes: Discriminated unions have the property that the
attribute type is constrained by the value of the
attribute
4.1.19 Instance
Type:
From: SMI,
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
instances
Elliott, et al. Informational [Page 11]
RFC 3216 SMIng Objectives December 2001
4.1.20 Row
Type:
From: SMI,
Description: SMIng must allow specifying pointers to rows
Motivation: It is common practice in MIBs and PIBs to point to
rows (see RowPointer, PIB-REFERENCES).
4.1.21 Constraints on
Type:
From:
Description: SMIng must allow specifying the types of objects
which a pointer may point
Motivation: Allows code generators to detect and reject
pointers automatically. Can also be used to
generate more reasonable implementation-specific data structures
Notes: Pointer constraints are a special case of attribute
constraints (Section 4.3.2) in which the prefix of the OID (row
instance pointer) value is limited to be only from a
table
4.1.22 Base Type
Type:
From: SMI,
Description: SMIng must support a fixed set of base types of
size and precision. The list of base types must not be
unless the SMI itself changes
Motivation: Interoperability
4.1.23 Extended Data
Type:
From: SMI,
Elliott, et al. Informational [Page 12]
RFC 3216 SMIng Objectives December 2001
Description: SMIng must support a mechanism to derive new types
which provide additional semantics (e.g., Counters, Gauges
Strings, etc.), from base types. It may be desirable to
allow the derivation of new types from derived types. New
must be as restrictive or more restrictive than the types
they are specializing
Motivation: SMI uses application types and textual conventions.
uses derived types
4.1.24 Units, Formats, and Default Values of Defined Types
Type:
From:
Description: In SMIv2 OBJECT-TYPE definitions may contain UNITS
DEFVAL clauses and TEXTUAL-CONVENTIONs may contain DISPLAY-HINTs
In a similar fashion units and default values must be
to defined types and format information must be applicable
attributes
Motivation: Some MIBs introduce TCs such as KBytes and every usage
the TC then specifies the UNITS "KBytes". It would
things if the UNITS were attached to the type definition itself
Notes: The SMIng WG must clarify the behavior if an attribute uses
defined type and both, the attribute and the defined type,
units/default/format information
4.1.25 Table Existence
Type:
From: SMI,
Description: SMIng must support INDEX, AUGMENTS, and EXTENDS in
SNMP/COPS-PR protocol mappings
Motivation: These three table existence relationships exist either
the SMIv2 or the SPPI
Elliott, et al. Informational [Page 13]
RFC 3216 SMIng Objectives December 2001
4.1.26 Table Existence Relationships (2)
Type:
From:
Description: SMIng must support EXPANDS and REORDERS relationships
the SNMP/COPS-PR protocol mappings
Motivation: A REORDERS statement allows indexing orders to
swapped. An EXPANDS statement formally states that there is a 1:
existence relationship between table rows
4.1.27 Attribute
Type:
From:
Description: An attribute group is a named, reusable set
attributes that are meaningful together. It can be reused as
type of attributes in other attribute groups (see also
4.1.28). This is similar to `structs' in C
Motivation: Required to map the same grouping of attributes into
and COPS-PR tables. Allows to do index reordering without
to redefine the attribute group. Allows to group
attributes together (e.g. InetAddressType, InetAddress).
The ability to group attributes provides an indication that
attributes are meaningful together
4.1.28
Type:
From:
Description: SMIng must provide support for the creation of
attribute groups from attributes of more basic types
potentially other attribute groups
Motivation: Simplifies the reuse of attribute groups such
InetAddressType and InetAddress pairs
Elliott, et al. Informational [Page 14]
RFC 3216 SMIng Objectives December 2001
Notes: Containment has the implicit existence constraint that if
instance of a contained attribute group exists, then
corresponding instance of the containing attribute group must
exist
4.1.29 Single
Type:
From:
Description: SMIng must provide support for mechanisms to
attribute groups through single inheritance
Motivation: Allows to extend attribute groups, like a
DiffServ scheduler, with attributes for a specific scheduler
without cut&paste
Notes: Single inheritance with multiple levels (e.g., C derives
B, and B derives from A) must be allowed
Inheritance has the implicit existence constraint that if
instance of a derived attribute group exists, then
corresponding instance of the base attribute group must
exist
Inheritance could help to add attributes to an attribute
that are specific to a certain protocol mapping and do not
in the protocol-neutral attribute group
4.1.30 Reusable vs. Final Attribute
Type:
From: NMRG,
Description: SMIng must differentiate between "final" and
attribute groups, where the reuse of attribute groups
inheritance and containment
Motivation: This information gives people more information
attribute groups can and should be used. It hinders them
misusing them
Notes: This objective attempts to convey the idea that some
groups are not meant to stand on their own and instead only
sense if contained within another attribute group
Elliott, et al. Informational [Page 15]
RFC 3216 SMIng Objectives December 2001
4.1.31
Type:
From: SMI,
Description: SMIng must provide mechanisms to define events
identify significant state changes
Motivation: These represent the protocol-independent events that
to SMI notifications or SPPI reports
4.1.32 Creation/
Type:
From: SMI,
Description: SMIng must support a mechanism to
creation/deletion operations for instances.
creation/deletion errors, such as INSTALL-ERRORS, must
supported
Motivation: Available for row creation in SMI, and available in SPPI
4.1.33 Range and Size
Type:
From: SMI,
Description: SMIng must allow specifying range and size
where applicable
Motivation: The SMI and SPPI both support range and size constraints
4.1.34
Type:
From:
Description: SMIng must allow the specification of
constraints on attributes. SMIng must allow the specification
multiple independent uniqueness constraints
Elliott, et al. Informational [Page 16]
RFC 3216 SMIng Objectives December 2001
Motivation: Knowledge of the uniqueness constraints on
allows to verify protocol specific mappings (e.g. INDEX clauses).
The knowledge can also be used by code generators to
generated implementation-specific data structures
4.1.35 Extension
Type:
From: SMI,
Description: SMIng must provide clear rules how one can extend
modules without causing interoperability problems "over the wire".
Motivation: SMIv2 and SPPI have extension rules
4.1.36 Deprecate Use of IMPLIED
Type:
From:
Description: The SMIng SNMP mapping must deprecate the use of
IMPLIED indexing schema
Motivation: IMPLIED is confusing and most people don't understand it
The solution (IMPLIED) is worse than the problem it is trying
solve and therefore for the sake of simplicity, the use of
should be deprecated
4.1.37 No
Type:
From:
Description: The SMIng language must avoid redundancy
Motivation: Remove any textual redundancy for things like
entries and SEQUENCE definitions, which only
specifications without providing any value
4.1.38 Compliance and
Type:
From: SMI,
Elliott, et al. Informational [Page 17]
RFC 3216 SMIng Objectives December 2001
Description: SMIng must provide a mechanism for compliance
conformance specifications for protocol-independent definitions
well as for protocol mappings
Motivation: This capability exists in SMIv2 and SPPI. The
proposal has the ability to express much of this information
the protocol-dependent layer. Some compliance or
information may be protocol-independent, therefore there is also
need to be able to express this information protocol-
part
4.1.39 Allow Refinement of All Definitions in Conformance
Type:
From:
Description: SMIv2, RFC 2580, Section 3.1 says
The OBJECTS clause, which must be present, is used to
each object contained in the conformance group. Each of
specified objects must be defined in the same
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 to put a not-accessible INDEX
into an OBJECT-GROUP. Hence, you can not refine its syntax in
compliance definition. For more details,
http://www.ibr.cs.tu-bs.de/ietf/smi-errata
Motivation: This error should not be repeated in SMIng
4.1.40
Type:
From:
Description: SMIng must provide a mechanism to group definitions
subject categories. Concrete instances may only exist in
scope of a given subject category or context
Motivation: To scope the categories to which a module applies.
SPPI this is used to allow a division of labor between
client types
Elliott, et al. Informational [Page 18]
RFC 3216 SMIng Objectives December 2001
4.1.41 Core Language Keywords vs. Defined
Type:
From:
Description: In SMI and SPPI modules some language keywords (
and a number of basetypes) have to be imported from different
language defining modules, e.g. OBJECT-TYPE, MODULE-IDENTITY
Integer32 must to be imported from SNMPv2-SMI and TEXTUAL
CONVENTION must be imported from SNMPv2-TC, if used. MIB
are continuously confused about these import rules. In SMIng
defined identifiers must be imported. All SMIng language
must be implicitly known and there must not be a need to
them from any module
Motivation: Reduce confusion. Clarify the set of language keywords
4.1.42 Instance
Type:
From: SMI,
Description: Instance naming in SMIv2 and SPPI is different.
must align the instance naming (either in the protocol
model or the protocol mappings).
Motivation: COPS-PR and SNMP have different instance
schemes that must be handled
Notes: A solution requires to investigate how close the
schemes dictated by the protocols are. Perhaps it is feasible
have a single instance naming scheme in both SNMP and COPS-PR
even though the current SPPI and SMIv2 are different
4.1.43 Length of
Type:
From:
Description: The allowed length of the various kinds of
must be extended from the current `should not exceed 32' (
even from the `must not exceed 64') rule
Motivation: Reflect current practice of definitions
Elliott, et al. Informational [Page 19]
RFC 3216 SMIng Objectives December 2001
Notes: The 32-rule was added back in the days where compilers
not deal with long identifiers. This rule is
violated these days and it does not make sense to keep it
4.1.44 Assign OIDs in the Protocol
Type:
From:
Description: SMIng must not assign OIDs to reusable definition
attributes, attribute groups, events, etc. Instead, SNMP
COPS-PR mappings must assign OIDs to the mapped items
Motivation: Assignment of OIDs in protocol neutral definitions
complicate reuse. OIDs of synonymous attributes are not the
in SMI and SPPI definitions. MIBs and PIBs are already
in different parts of the OID namespace
4.2 Nice-to-Have
This section represents the list of recommended objectives that
be nice to have. However, these are not automatically thought of
accepted objectives as, for example, they may entail a non-
amount of work in underlying protocols to support or they may
regarded as less important than other contradicting objectives
are accepted
4.2.1
Type:
From:
Description: SMIng should support a mechanism to define
signatures (parameters, return values, exception) that
implemented on agents
Motivation: Methods are needed to support the definition
operational interfaces such as found in [RFC2925] (ping
traceroute and lookup operations). Also, the ability to
constructor/destructor interfaces could address issues such
encountered with SNMP's RowStatus solution
Notes: Is it possible to do methods without changing the
protocol? There is agreement that methods are useful,
disagreement upon the impact - one end of the spectrum sees
as a documentation tool for existing SNMP capabilities, while
Elliott, et al. Informational [Page 20]
RFC 3216 SMIng Objectives December 2001
other end sees this as a protocol update, moving forward,
natively support methods. The proposal is to wait and see if
is practical to implement as a syntax that is useful and can
to the protocol
4.2.2
Type:
From:
Description: SMIng should support a standard format for unions
Motivation: Allows an attribute to contain one of many types
values. The lack of unions has also lead to relatively
sparse table work-around in some DISMAN mid-level managers
Despite from discriminated unions (see Section 4.1.18), this
of union has no accompanied explicit discriminator attribute
selects the union's type of value
Notes: The thought is that SNMP and COPS-PR can already
unions because they do not care about what data type goes with
particular OID
4.2.3 Float Data
Type:
From: WG,
Description: SMIng should support the base data types Float32,
Float64, Float128.
Motivation: Missing base types can hurt later on, because they
be added without changing the language, even as an
extension. Lesson learned from the SMIv1/v2 debate
Counter64/Integer64/...
Notes: There is no mention as to whether or not the
protocols will have to natively support float data types. This
left to the mapping. However, it seems imperative that the
data type needs to be added to the set of intrinsic types in
SMIng language at the creation of the language as it will
impossible to add them later without changing the language
Elliott, et al. Informational [Page 21]
RFC 3216 SMIng Objectives December 2001
4.2.4
Type:
From:
Description: 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 thus SMI and SPPI comments) have
a constant source of confusion. People use arbitrary
strings of dashes (`-----------') in the wrong assumption
this is always treated as a comment. Some implementations try
accept these syntactically wrong constructs which even
confusion. We should get rid of this problem
Notes: If the SMIng working group adopts a C-like syntax, then
C++/Java single-line comment should be adopted as well
4.2.5 Referencing Tagged
Type:
From:
Description: PIB and MIB row attributes reference a group of
in another table. SPPI formalizes this by introducing PIB-TAG
PIB-REFERENCES clauses. This functionality should be retained
SMIng
Motivation: SPPI formalizes tag references. Some MIBs also use
references (see SNMP-TARGET-MIB in RFC2573) even though SMIv2
not provide a formal notation
4.2.6
Type:
From:
Description: SMIng should allow the definition of a SEQUENCE
attributes or attribute groups (Section 4.1.27).
Motivation: The desire for the ability to have variable-length
multi-valued objects
Elliott, et al. Informational [Page 22]
RFC 3216 SMIng Objectives December 2001
Notes: Some issues with arrays are still unclear. As long as
are no concepts to solve the problems with access semantics (
to achieve atomic access to arbitrary-sized arrays) and
mappings to SNMP and COPS-PR protocol operations, arrays cannot
more than a nice to have objective
4.2.7
Type:
From:
Description: Informational text (DESCRIPTION, REFERENCE, ...)
allow i18nized encoding, probably UTF-8.
Motivation: There has been some demand for i18n in the past. The
RFC 2277 demands for internationalization
Notes: Although English is the language of IETF documents,
should allow other languages for private use
4.2.8 Separate Data Modelling from Management Protocol
Type:
From:
Description: It should be possible to separate the domain
data modelling work from the network management protocol
work
Motivation: Today, working groups designing new protocols are
to care about the design of SNMP MIBs and maybe COPR-PR PIBs
manage the new protocol. This means that experts in a
domain are faced with details of at least one foreign (
management) technology. This leads to hard work and long
processes. It would be a win to separate the task of pure
modelling which can be done by the domain experts easily from
network management protocol specific mappings. The mapping
SNMP and/or COPS-PR can be done (a) later separately and (b)
network management experts. This required NM expertise no
hinders the progress of the domain specific working groups
Elliott, et al. Informational [Page 23]
RFC 3216 SMIng Objectives December 2001
4.3 Rejected
This section represents the list of objectives that were
during the discussion on the objectives. Those objectives that
been rejected need not be addressed by SMIng. This does not
that they must not be addressed
4.3.1 Incomplete
Type:
From:
Description: Reality sucks. All information expressed in SMIng
not be directly translatable to a MIB or PIB construct, but
information should be able to be conveyed in documentation or
other mechanisms
Motivation: SMIng working group requires this to ease transition
Notes: The SMIng language itself cannot require what compilers
that translate SMIng into something else. So this seems to
out of the scope of the current working group charter
4.3.2 Attribute Value
Type:
From:
Description: SMIng should provide mechanisms to formally
constraints between values of multiple attributes
Motivation: Constraints on attribute values occur where one or
attributes may affect the value or range of values for
attribute. One such relationship exists in IPsec, where the
of security algorithm determines the range of possible values
other attributes such as the corresponding key size
Notes: This objective as is has been rejected as too general,
therefore virtually impossible to implement. However,
that are implicit with discriminated unions (Section 4.1.18),
enumerated types (Section 4.1.17), pointer constraints (
4.1.21)), etc., are accepted and these implicit constraints
mentioned in the respective objectives
Elliott, et al. Informational [Page 24]
RFC 3216 SMIng Objectives December 2001
4.3.3 Attribute Transaction
Type:
From:
Description: SMIng should provide a mechanism to formally
that certain sets of attributes can only be modified
combination
Motivation: COPS-PR always does operations on table rows in a
transaction. There are SMIv2 attribute combinations that need
be modified together (such as InetAddressType, InetAddress).
Notes: Alternative is to either use Methods (Section 4.2.1) or
that all attributes in an attribute group (Section 4.1.27) are
be considered atomic
4.3.4 Method
Type:
From:
Description: Method definitions should provide constraints
parameters
Motivation: None
Notes: Unless methods (Section 4.2.1) are done, there is no use
this. Furthermore, this objective has not been motivated by
proponent
4.3.5 Agent
Type:
From:
Description: SMIng should provide mechanisms to describe
implementations
Motivation: To permit manager to determine variations from
standard for an implementation
Notes: Agent capabilities should not be part of SMIng, but
instead be a separate capabilities table
Elliott, et al. Informational [Page 25]
RFC 3216 SMIng Objectives December 2001
4.3.6
Type:
From: NMRG,
Description: Ability to formally depict existence dependency,
dependency, aggregation, containment, and other
between attributes or attribute groups
Motivation: Helps humans to understand the conceptual model of
module. Helps implementers of MIB compilers to generate
`intelligent' code
Notes: This objective was deemed too general to be useful and
the individual types of relationship objectives (e.g., pointers
inheritance, containment, etc.) are evaluated on a case-by-
basis with the specific relationships deemed useful being
as accepted objectives
4.3.7
Type:
From:
Description: SMIng should support a mechanism to formally
procedures that are used by managers when interacting with
agent
Motivation: None
Notes: This objective has not been motivated by any proponent
4.3.8
Type:
From:
Description: SMIng should provide mechanisms to explicitly
associations
Motivation: None
Notes: This objective has not been motivated by any proponent
Elliott, et al. Informational [Page 26]
RFC 3216 SMIng Objectives December 2001
4.3.9 Association
Type:
From:
Description: Cardinalities between associations should be
defined
Motivation: If you have an association between attribute groups A
B, the cardinality of A indicates how many instances of A may
associated with a single instance of B. Our discussions
Minneapolis indicated that we want to convey "how many"
are associated in order to define the best mapping algorithm -
whether a new table, a single pointer, etc. For example, do
use RowPointer or an integer index into another table? Do we
to a table that holds instances of the association/
itself
Notes: Without associations (Section 4.3.8), this has no use
4.3.10 Categories of
Type:
From:
Description: The SMIng documents should give clear guidance on
kind of information (with respect to generality, type/
group/extension/..) should be put in which kind of a module
E.g., in SMIv2 we don't like to import Utf8String from SYSAPPL
MIB, but we also do not like to introduce a redundant definition
A module review process should probably be described that
that generally useful definitions do not go into device or
specific modules
Motivation: Bad experience with SMIv2.
Notes: It is not clear how this can be done with the language to
created by SMIng WG
4.3.11 Mapping Modules to
Type:
From:
Elliott, et al. Informational [Page 27]
RFC 3216 SMIng Objectives December 2001
Description: There should be a clear statement how SMIng modules
mapped to files (1:1, n:1?) and how files should be named (
module name in case of 1:1 mapping?).
Motivation: SMI implementations show up a variety of
extensions (.txt, .smi, .my, none). Some expect all modules in
single file, others don't. This makes it more difficult
exchange modules
Notes: This is just an implementation detail and is best left to
BCP and not made a part of the language definition
4.3.12 Simple
Type:
From:
Description: The grammar of the language should be as simple
possible. It should be free of exception rules. A measurement
simplicity is shortness of the ABNF grammar
Motivation: Ease of implementation. Ease of learning/understanding
Notes: This seems like an obvious objective, however shortness of
ABNF grammar is not necessarily a reflection of the simplicity
the grammar
4.3.13 Place of Module
Type:
From:
Description: Module specific information (organization, contact
description, revision information) should be bound to the
itself and not to an artificial node (like SMIv2 MODULE-IDENTITY).
Motivation: Simplicity and design cleanup
Notes: This does not seem to be a problem with the current SMI
Although simplification is a good thing, this detail is
considered an objective
Elliott, et al. Informational [Page 28]
RFC 3216 SMIng Objectives December 2001
4.3.14 Module
Type:
From:
Description: Currently the namespace of modules is flat and there
no structure in module naming causing the potential risk of
clashes. Possible solutions
* Assume module names are globally unique (just as SMIv1/v2),
just give some recommendations on module names
* Force all organizations, WGs and vendors to apply a name
(e.g. CISCO-GAGA-MIB, IETF-DISMAN-SCRIPT-MIB?).
* Force enterprises to apply a prefix based on the
number (e.g. ENT2021-SOME-MIB).
* Put module names in a hierarchical domain based namespace (e.g
DISMAN-SCRIPT-MIB.ietf.org).
Motivation: Reduce risk of module name clashes
Notes: Some aspects of this objective overlap with other
(namespace control (Section 4.1.9)) and other aspects were
best left to a BCP
4.3.15 Hyphens in
Type:
From:
Description: There has been some confusion whether hyphens
allowed in SMIv2 identifiers: Module names are allowed to
hyphens. Node identifiers usually are not. But for
`mib-2' is a frequently used identifier that contains a hyphen
to its SMIv1 origin, when hyphen were not disallowed. Similarly
a number of named numbers of enumeration types contain
violating an SMIv2 rule
SMIng should simply allow hyphens in all kinds of identifiers.
exceptions
Motivation: Reduce confusion and exceptions. Requires, however,
implementation mappings properly quote hyphens where appropriate
Elliott, et al. Informational [Page 29]
RFC 3216 SMIng Objectives December 2001
Notes: This nit-picking is not worth to be subject to the
on objectives. However, SMIng should care about the fact
compilers have to map SMIng to programming languages where
hyphen is a minus and thus not allowed in identifiers
5. Security
This document defines objectives for a language with which to
and read descriptions of management information. The language
has no security impact on the Internet
6.
Thanks to Dave Durham, whose work on the original NIM (
Information Model) draft was used in generating this document
Thanks to Andrea Westerinen for her contributions on the original
requirements and SMIng objectives drafts
7.
[1] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "
Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990.
[2] McCloghrie, K., Case, J., Rose, M. and S. Waldbusser, "
Operations for Version 2 of the Simple Network
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, "
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
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, "
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
Provisioning Information (SPPI)", RFC 3159, August 2001.
Elliott, et al. Informational [Page 30]
RFC 3216 SMIng Objectives December 2001
8. Authors'
Chris
Cisco
7025 Kit Creek
Research Triangle Park, NC 27709
EMail: chelliot@cisco.
David
Enterasys
35 Industrial
P.O. Box 5005
Rochester, NH 03866-5005
EMail: dbh@enterasys.
Jamie
Intel
MS JF3-206
2111 NE 25th Ave
Hillsboro, OR 97124
EMail: jamie.jason@intel.
Juergen
TU
Muehlenpfordtstr. 23
38106
EMail: schoenw@ibr.cs.tu-bs.
URI: http://www.ibr.cs.tu-bs.de
Elliott, et al. Informational [Page 31]
RFC 3216 SMIng Objectives December 2001
Frank
TU
Muehlenpfordtstr. 23
38106
EMail: strauss@ibr.cs.tu-bs.
URI: http://www.ibr.cs.tu-bs.de
Walter
Ellacoya
7 Henry Clay Dr
Merrimack, NH. 03054
EMail: wweiss@ellacoya.
Elliott, et al. Informational [Page 32]
RFC 3216 SMIng Objectives December 2001
9. Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Elliott, et al. Informational [Page 33]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
