Network Working Group C. Elliott
Internet-Draft Cisco Systems
Expires: December 11, 2001 D. Harrington
Enterasys Networks
J. Jason
Intel Corporation
J. Schoenwaelder
F. Strauss
TU Braunschweig
W. Weiss
Ellacoya Networks
June 12, 2001
SMIng Requirements
draft-ietf-sming-reqs-02
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 11, 2001.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document describes the requirements of a data modeling language,
suitable for the modeling of network management constructs, that can
be directly mapped into SNMP [1] and COPS-PR [9] protocol PDUs.
Elliott, et. al. Expires December 11, 2001 [Page 1]
Internet-Draft SMIng Requirements June 2001
Additionally, it is desirable that if possible the language should be
able to be translated into SMIv2 [3], [4], [5] and/or SPPI [10].
This document identifies requirements of an updated data modeling
language for SNMP and COPS-PR. The purpose of this document is to
ensure that subsequent language specification is complete and
consistent with the stated requirements.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Background . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Specific Requirements for SMIng . . . . . . . . . . . . . 6
4.1 Accepted Requirements . . . . . . . . . . . . . . . . . . 7
4.1.1 The Set of Specification Documents . . . . . . . . . . . . 7
4.1.2 Textual Representation . . . . . . . . . . . . . . . . . . 7
4.1.3 Human Readability . . . . . . . . . . . . . . . . . . . . 7
4.1.4 Machine Readability . . . . . . . . . . . . . . . . . . . 7
4.1.5 Accessibility . . . . . . . . . . . . . . . . . . . . . . 8
4.1.6 Language Extensibility . . . . . . . . . . . . . . . . . . 8
4.1.7 Special Characters in Text . . . . . . . . . . . . . . . . 8
4.1.8 Naming . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.9 Namespace Control . . . . . . . . . . . . . . . . . . . . 9
4.1.10 Modules . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.11 Module Conformance . . . . . . . . . . . . . . . . . . . . 9
4.1.12 Arbitrary Unambiguous Identities . . . . . . . . . . . . . 10
4.1.13 Protocol Independence . . . . . . . . . . . . . . . . . . 10
4.1.14 Protocol Mapping . . . . . . . . . . . . . . . . . . . . . 10
4.1.15 Translation to Other Data Definition Languages . . . . . . 10
4.1.16 Base Data Types . . . . . . . . . . . . . . . . . . . . . 11
4.1.17 Enumerations . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.18 Discriminated Unions . . . . . . . . . . . . . . . . . . . 11
4.1.19 Instance Pointers . . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . 13
4.1.24 Units and Default Values of Defined Types . . . . . . . . 13
4.1.25 Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.26 Tables . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.27 Table Existence Relationships . . . . . . . . . . . . . . 14
4.1.28 Table Relationships . . . . . . . . . . . . . . . . . . . 14
4.1.29 Structures . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.30 Containment . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.31 Single Inheritance . . . . . . . . . . . . . . . . . . . . 15
4.1.32 Events . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.33 Creation/Deletion . . . . . . . . . . . . . . . . . . . . 16
Elliott, et. al. Expires December 11, 2001 [Page 2]
Internet-Draft SMIng Requirements June 2001
4.1.34 Range and Size Constraints . . . . . . . . . . . . . . . . 16
4.1.35 Uniqueness . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.36 Extension Rules . . . . . . . . . . . . . . . . . . . . . 16
4.1.37 Deprecate Use of IMPLIED Keyword . . . . . . . . . . . . . 16
4.1.38 No Redundancy . . . . . . . . . . . . . . . . . . . . . . 17
4.1.39 Compliance and Conformance . . . . . . . . . . . . . . . . 17
4.1.40 Allow Refinement of All Definitions in Conformance
Statements . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Nice-to-Have Requirements . . . . . . . . . . . . . . . . 18
4.2.1 Methods . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.2 Unions . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.3 Abstract vs. Concrete Structures . . . . . . . . . . . . . 19
4.2.4 Float Data Types . . . . . . . . . . . . . . . . . . . . . 19
4.2.5 Comments . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3 Rejected Requirements . . . . . . . . . . . . . . . . . . 20
4.3.1 Incomplete Translations . . . . . . . . . . . . . . . . . 20
4.3.2 Instance Naming . . . . . . . . . . . . . . . . . . . . . 20
4.3.3 Attribute Value Constraints . . . . . . . . . . . . . . . 20
4.3.4 Existence Constraints . . . . . . . . . . . . . . . . . . 21
4.3.5 Ordering Constraints . . . . . . . . . . . . . . . . . . . 21
4.3.6 Attribute Transaction Constraints . . . . . . . . . . . . 21
4.3.7 Method Constraints . . . . . . . . . . . . . . . . . . . . 22
4.3.8 Categories . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3.9 Agent Capabilities . . . . . . . . . . . . . . . . . . . . 22
4.3.10 Relationships . . . . . . . . . . . . . . . . . . . . . . 22
4.3.11 Procedures . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3.12 Associations . . . . . . . . . . . . . . . . . . . . . . . 23
4.3.13 Association Cardinalities . . . . . . . . . . . . . . . . 23
4.3.14 Categories of Modules . . . . . . . . . . . . . . . . . . 24
4.3.15 Length of Identifiers . . . . . . . . . . . . . . . . . . 24
4.3.16 Why Are So Many SMIv1/v2 Parsers So Error Tolerant? . . . 24
4.3.17 Core Language Keywords vs. Defined Identifiers . . . . . . 25
4.3.18 Internationalization . . . . . . . . . . . . . . . . . . . 25
4.3.19 Mapping Modules to Files . . . . . . . . . . . . . . . . . 25
4.3.20 Simple Grammar . . . . . . . . . . . . . . . . . . . . . . 26
4.3.21 Place of Module Information . . . . . . . . . . . . . . . 26
4.3.22 Fully Qualified Identifiers . . . . . . . . . . . . . . . 26
4.3.23 Readable Revision Date Representation . . . . . . . . . . 26
4.3.24 Make Status Information Optional . . . . . . . . . . . . . 27
4.3.25 Remove OIDs from the Core Language . . . . . . . . . . . . 27
4.3.26 Module Namespace . . . . . . . . . . . . . . . . . . . . . 28
4.3.27 Hyphens in Identifiers . . . . . . . . . . . . . . . . . . 28
4.3.28 Referencing a Group of Instances of a Structure . . . . . 28
5. Security Considerations . . . . . . . . . . . . . . . . . 29
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 29
References . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 30
A. Mailing List Discussions . . . . . . . . . . . . . . . . . 32
Elliott, et. al. Expires December 11, 2001 [Page 3]
Internet-Draft SMIng Requirements June 2001
Full Copyright Statement . . . . . . . . . . . . . . . . . 42
Elliott, et. al. Expires December 11, 2001 [Page 4]
Internet-Draft SMIng Requirements June 2001
1. Introduction
This document describes the requirements for the definition of a new
object-oriented, data modeling language that can be mapped directly
into SNMP and COPS-PR protocol PDUs. It may also be translated into
SMIv2 MIBs and SPPI PIBs. Concepts such as structures, attributes,
methods, conventions for organization into reusable data structures,
and mechanisms for representing relationships are discussed.
Conventions used in this document:
2. Motivation
As networking technology has evolved, a diverse set of technologies
has been deployed to manage the resulting products. These vary from
Web based products, to standard management protocols and text
scripts. The underlying systems to be manipulated are represented in
varying ways including implicitly in the system programming, via
proprietary data descriptions, or with standardized descriptions
using a range of technologies including MIBs [6], PIBs [11], or LDAP
[7] schemas. The result is that network applications and services
such as DHCP or Differentiated Services may be represented in many
different inconsistent fashions.
The SMIng working group will develop a new modeling language to align
the languages defined in the SMIv2 and SPPI documents (the languages
for writing MIBs and PIBs), since these are very similar.
Another motivation is to permit a more expressive and complete
representation of the modeled information. Examples of additional
expressiveness and completeness that are considered are the ability
to clearly define relationships between objects, the expression of
constraints on objects and properties, and the ability to define
methods. These additional features are discussed in subsequent
sections.
3. Background
The Network Management Research Group (NMRG) of the Internet Research
Task Force (IRTF) has researched the issues of creating a protocol-
independent data modeling language that could be used by multiple
protocols. Because SMIv2 and SPPI are very similar, the NMRG focused
on merging these two languages, but also researched ways to abstract
the requirements to produce a language that could be used for other
protocols, such as LDAP and Diameter. The NMRG has published the
results of their work in [12], and has submitted their specification
as one proposal to consider in the development of the SMIng language.
Elliott, et. al. Expires December 11, 2001 [Page 5]
Internet-Draft SMIng Requirements June 2001
The SMIng Working Group has accepted their submission for
consideration, and to use their proposal to better understand the
requirements and possible obstacles to be overcome. Where useful,
the NMRG proposal has been referenced in the details below.
4. Specific Requirements for SMIng
The following sections define the requirements for the definition of
an object-oriented, data-modeling language. The draft captures the
results of the working group discussions regarding the SMIng
requirements process. It is broken up into three sections: accepted
requirements (Section 4.1), nice-to-have requirements (Section 4.2),
and rejected requirements (Section 4.3). Appendix A contains the
requirements discussion that was generated on the SMIng mailing list.
Each requirement has the following information:
o Number: the original requirement number (as a means for cross
referencing)
o Type: a field that identifies the type of requirement, using one
of the following values:
* basic: considered a basic requirement for SMIng and is
contained in SMIv2 and/or SPPI.
* align: supported in different ways in SMIv2 and SPPI and they
must be aligned.
* must: considered a fix for a known problem in SMIv2 and/or
SPPI.
* should: modifies something that is often misused, or would be
nice to have if it can be easily done and does not cause
additional complexity or delay.
* new: considered a new feature that is not required in SMIng,
but could be added if working group consensus to do so is
reached.
o From: a field that defines the origin of the requirement and that
contains one or more of the following values:
* SMI: exists in SMIv2.
* SPPI: exists in SPPI.
* NMRG: exists in the current NMRG specification proposal, but
not in SMIv2 or SPPI.
* Charter: exists in working group charter.
* WG: proposed during working group discussions.
* Individual: proposed by working group participant.
o Description: a quick description of the requirement.
o Motivation: rationale for the requirement.
o Notes: optional notes about a requirement. For example, for nice-
to-have or rejected this may contain reasoning why this
requirement is not required by the SMIng working group, but
justification why it should be considered anyway. Notes may be
the opinions of the requirements process participants and as such
should not be taken as consensus of the working group or the
Elliott, et. al. Expires December 11, 2001 [Page 6]
Internet-Draft SMIng Requirements June 2001
recommendation of the requirements editing team.
4.1 Accepted Requirements
This section represents the list of requirements that have been
accepted by the SMIng working group.
4.1.1 The Set of Specification Documents
Number: 73
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 should de defined in
one document and must be independent of external specifications.
Motivation: Self-containment.
4.1.2 Textual Representation
Number: 1
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
Number: 2
Type: basic
From: WG
Description: The syntax must make it easy for humans to directly read
and write SMIng modules. It should be possible for SMIng module
authors to produce SMIng modules with text editing tools.
Motivation: The syntax should make it easy for humans to read and
write SMIng modules.
4.1.4 Machine Readability
Number: 3
Type: basic
From: SMI, SPPI
Description: The syntax should make it easy to implement parsers. A
complete ABNF specification of the grammar is desirable.
Furthermore, the language should forbid things like forward
references unless they are unavoidable.
Motivation: A complete specification of the language grammar in ABNF
Elliott, et. al. Expires December 11, 2001 [Page 7]
Internet-Draft SMIng Requirements June 2001
encourages the use of compiler toolkits to construct solid
parsers. Avoiding unnecessary forward references simplifies
parser internal data management and allows for early error
detection.
4.1.5 Accessibility
Number: 17
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 non- accessible. Align PIB-
ACCESS and MAX-ACCESS, and PIB-MIN-ACCESS and MIN-ACCESS.
Motivation: Alignment.
4.1.6 Language Extensibility
Number: 52
Type: new
From: NMRG
Description: The language should have characteristics, so that future
modules can contain information of future syntax without breaking
original SMIng parsers.
E.g., when SMIv2 introduced REFERENCEs it would have been nice if
it would not have broken SMIv1 parsers.
Motivation: Achieve language extensibility without breaking core
compatibility.
4.1.7 Special Characters in Text
Number: 57
Type: new
From: Individual
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
Number: 4 & 5 combined
Type: basic
From: SMI, SPPI
Description: SMIng must provide mechanisms to uniquely identify
Elliott, et. al. Expires December 11, 2001 [Page 8]
Internet-Draft SMIng Requirements June 2001
attributes, groups of attributes, and events. It is necessary to
specify how name collisions are handled.
Motivation:
4.1.9 Namespace Control
Number: 5
Type: basic
From: SMI, SPPI
Description: There should be a hierarchical, centrally-controlled
namespace for standard named items, and a distributed namespace
should 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 but with 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 employed by the Java
programming language with a central naming authority assigning the
top-level names.
The working group has to make a determination as to how best to
handle namespace control (e.g. a BCP).
4.1.10 Modules
Number: 6
Type: basic
From: SMI, SPPI
Description: SMIng must provide a mechanism for uniquely identifying
a module, and specifying the status, contact person, revision
information, and the 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
Number: 6
Type: basic
From: SMI, SPPI
Description: SMIng must provide mechanisms to detail the minimum
Elliott, et. al. Expires December 11, 2001 [Page 9]
Internet-Draft SMIng Requirements June 2001
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
Number: 66
Type: basic
From: SMI
Description: SMI allowed the use of OBJECT-IDENTITIES to define
unambiguous identities without the need of a central registry.
SMI uses OIDs to represent values that represent references 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 requirement. 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
Number: 7
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 may be used with multiple protocols.
4.1.14 Protocol Mapping
Number: 8
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 the progress on other requirements.
Motivation: SMIng working group charter.
4.1.15 Translation to Other Data Definition Languages
Number: 9
Type: basic
From: Charter
Elliott, et. al. Expires December 11, 2001 [Page 10]
Internet-Draft SMIng Requirements June 2001
Description: SMIng language constructs should, 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 while not placing an unnecessary burden on MIBs/PIBs that
are already on the standards track.
4.1.16 Base Data Types
Number: 12
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, must fix in SMI.
4.1.17 Enumerations
Number: 19
Type: basic
From: SMI, SPPI
Description: SMIng should provide support for enumerations.
Enumerated values must be a part of the enumeration definition.
Motivation: SMIv2 already has enumerated numbers and OIDs that can be
used to identify things.
Notes: Enumerations have the implicit constraint that the attribute
is constrained to the values for the enumeration.
4.1.18 Discriminated Unions
Number: 32
Type: should
From: WG
Description: SMIng must support a standard format for discriminated
unions.
Motivation: Allows to group related attributes together, such as
InetAddressType (discriminator) and InetAddress, InetAddressIPv4,
InetAddressIPv6 (union). The lack of discriminated unions has
also lead to relatively complex sparse table work-around in some
DISMAN mid-level manager MIBs.
Notes: SMIng must support discriminated unions, and should support
unions in general (Section 4.2.2). Discriminated unions have the
implicit constraint that the union attribute type is constrained
by the discriminator attribute.
Elliott, et. al. Expires December 11, 2001 [Page 11]
Internet-Draft SMIng Requirements June 2001
4.1.19 Instance Pointers
Number: 14
Type: basic
From: 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
Number: 15
Type: align
From: SMI, SPPI
Description: SMIng must allow specifying pointers to rows. A row
pointer is a special case of an instance pointer.
Motivation: It is common practice in MIBs and PIBs to point to other
rows (see RowPointer, PIB-REFERENCES).
4.1.21 Constraints on Pointers
Number: 23
Type: basic
From: SPPI
Description: SMIng must allow specifying the types of objects to
which a pointer may point.
Motivation: Allows code generators to detect and reject illegal
pointers automatically. 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.3) in which the prefix of the OID (row or
instance pointer) value is limited to be only from a particular
table.
4.1.22 Base Type Set
Number: 16
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 should not be
extensible unless the SMI itself changes.
Motivation: Interoperability.
Elliott, et. al. Expires December 11, 2001 [Page 12]
Internet-Draft SMIng Requirements June 2001
4.1.23 Extended Data Types
Number: 13 & 18 combined
Type: align
From: SMI, SPPI
Description: SMIng must allow a mechanism to allow types to be
defined as new types that provide additional semantics (e.g.,
Counters, Gauges, Strings, etc.). It may be desirable to also
allow the derivation of new types from derived types. New types
must be as restrictive or more restrictive than the types that
they are specializing.
Motivation: SMI uses application types and textual conventions. SPPI
uses derived types.
4.1.24 Units and Default Values of Defined Types
Number: 65
Type: new
From: NMRG
Description: In SMIv2 OBJECT-TYPE definitions may contain UNITS and
DEFVAL clauses and TEXTUAL-CONVENTIONs may contain DISPLAY-HINTs.
In a similar fashion units and default values should be applicable
to defined types and format information should be applicable to
attributes.
Motivation: Some MIBs introduce TCs such as KBytes and every usage of
the TC then specifies the UNITS "KBytes". It would simplify
things if the UNITS were attached to the type definition itself.
Note that SMIng must clarify the behavior, if an attribute uses a
defined type and both, the attribute and the defined type, have
units/default/format information.
4.1.25 Arrays
Number: 39
Type: new
From: WG
Description: SMIng should allow the definition of a SEQUENCE OF
attributes or structures (Section 4.1.29).
Motivation: The desire for the ability to have variable-length,
multi-valued objects.
Notes: There are fixed- and variable-size arrays, however fixed-size
arrays are really just a constrained kind of variable-size arrays.
Variable arrays can map to the EXPANDS clause - using the index of
the parent and the index of the contained array table with the
lifetime of the child table controlled by the parent table. The
EXPANDS clause formally states that there is a 1:n existence
relationship between tables and for the n instances to exist in
Elliott, et. al. Expires December 11, 2001 [Page 13]
Internet-Draft SMIng Requirements June 2001
the child table, the corresponding instance must exist in the
parent table.
Conceptually, arrays map to variable-sized tables in tables. If
arrays are to be supported then the general problem of variable-
sized tables in tables should be solved (vs. solving a very
specific problem such as a fixed-sized table in table).
4.1.26 Tables
Number: 25
Type: basic
From: SMI, SPPI
Description: SMIng should provide a mechanism for grouping attributes
as tables.
Motivation:
4.1.27 Table Existence Relationships
Number: 26
Type: basic
From: SMI, SPPI
Description: SMIng should support INDEX, AUGMENTS, and EXTENDS.
Motivation: These three table existence relationships that exist
either in the SMIv2 or the SPPI.
4.1.28 Table Relationships
Number: 48
Type: new
From: WG
Description: SMIng should support REORDERS clauses.
Motivation: A REORDERS statement allows to swap indexing orders
without having to redefine the whole table.
Notes: The EXPANDS clause portion was removed from this requirement
and is mentioned in Arrays (Section 4.1.25).
4.1.29 Structures
Number: 33
Type: new
From: NMRG
Description: A structure is a non-divisible, extensible grouping of
attributes that are meaningful together.
Motivation: Required to map the same grouping of attributes into SNMP
and COPS-PR tables. Allows to do index reordering without having
to redefine the grouping of attributes. Allows to group related
attributes together (e.g. InetAddressType, InetAddress).
Elliott, et. al. Expires December 11, 2001 [Page 14]
The ability to group attributes in a structure provides an
indication that the attributes are meaningful together.
Notes: Protocols must ensure that when sending structures across the
wire that (1) all attributes of the structure are sent together
and (2) the order of the attributes is maintained.
4.1.30 Containment
Number: 40
Type: new
From: NMRG
Description: SMIng must provide support for the creation of new
compound types from more basic (potentially compound) types.
Motivation: Simplifies the reuse attribute combination such as
InetAddressType and InetAddress pairs.
Containment has the implicit existence constraint that if an
instance of contained structure exists, then the corresponding
instance of the containing structure must also exist.
4.1.31 Single Inheritance
Number: 34
Type: new
From: NMRG
Description: SMIng should provide support for mechanisms to extend
attribute groupings (structures) through single inheritance.
Motivation: Allows to extend grouping of attributes, like a generic
DiffServ scheduler, with attributes for a specific scheduler,
without cut&paste.
Notes: If an instance of a derived structure exists, then the
corresponding instance of the base structure implicitly exists
within the derived structure.
Single inheritance with multiple levels (e.g., C derives from B,
and B derives from A) must be allowed.
Inheritance has the implicit existence constraint that if an
instance of derived structure exists, then the corresponding
instance of the base structure must also exist.
4.1.32 Events
Number: 20
Type: basic
From: SMI, SPPI
Description: SMIng must provide mechanisms to define events which
identify significant state changes.
Motivation: These represent the protocol-independent events that lead
to SMI notifications or SPPI reports.
Elliott, et. al. Expires December 11, 2001 [Page 15]
Internet-Draft SMIng Requirements June 2001
4.1.33 Creation/Deletion
Number: 21
Type: basic
From: SMI, SPPI
Description: SMIng should support a mechanism to define
creation/deletion operations for instances. Specific
creation/deletion errors, such as INSTALL-ERRORS, must be
supported.
Motivation: Available for row creation in SMI, and available in SPPI.
4.1.34 Range and Size Constraints
Number: 22
Type: basic
From: SMI, SPPI
Description: SMIng must allow specifying range and size constraints
where applicable.
Motivation: The SMI and SPPI both support range and size constraints.
4.1.35 Uniqueness
Number: 24
Type: basic
From: SPPI
Description: SMIng must allow the specification of uniqueness
constraints on attributes. SMIng should allow the specification
of independent uniqueness constraints.
Motivation: Knowledge of the uniqueness constraints on attributes
allows to verify protocol specific mappings (e.g. INDEX clauses).
The knowledge can also be used by code generators to improve
generated implementation-specific data structures.
4.1.36 Extension Rules
Number: 27
Type: basic
From: SMI
Description: SMIng must provide clear rules how one can extend SMIng
modules without causing interoperability problems "over the wire".
Motivation: SMIv2 and SPPI have extension rules.
4.1.37 Deprecate Use of IMPLIED Keyword
Number: 30
Type: should
From: SMI
Description: The SMIng SNMP mapping should deprecate the use of the
Elliott, et. al. Expires December 11, 2001 [Page 16]
Internet-Draft SMIng Requirements June 2001
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 to
solve and therefore for the sake of simplicity, the use of IMPLIED
should be deprecated.
4.1.38 No Redundancy
Number: 31
Type: should
From: SMI
Description: The SMIng language should avoid redundancy.
Motivation: Remove any textual redundancy for things like table
entries and SEQUENCE definitions, which only increase
specifications without providing any value.
4.1.39 Compliance and Conformance
Number: 50
Type: basic
From: SMIv2, SPPI
Description: SMIng should provide a mechanism for compliance and
conformance specifications for protocol-independent definitions as
well as for protocol mapping.
Motivation: This capability exists in SMIv2 and SPPI. The NMRG
proposal has the ability to express much of this information at
the protocol-independent layer, thus reducing redundant
information. Some compliance or conformance information may be
protocol-specific, therefore there is also a need to be able to
express this information in the mapping.
4.1.40 Allow Refinement of All Definitions in Conformance Statements
Number: 74
Type: must
From: Individual
Description: 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 to put a not-accessible INDEX object
Elliott, et. al. Expires December 11, 2001 [Page 17]
Internet-Draft SMIng Requirements June 2001
into an OBJECT-GROUP. Hence, you can not refine its syntax in a
compliance definition. For more details, see
http://www.ibr.cs.tu-bs.de/ietf/smi-errata/
Motivation: This error should not be repeated in SMIng.
4.2 Nice-to-Have Requirements
This section represents the list of recommended requirements that
would be nice to have. However, these are not automatically thought
of as accepted requirements as, for example, they may entail a non-
trivial amount of work in underlying protocols to support.
4.2.1 Methods
Number: 37
Type: new
From: WG
Description: SMIng should support a mechanism to define method
signatures (parameters, return values, exception) that are
implemented on agents.
Motivation: Methods are needed to support the definition of
operational interfaces such as found in [RFC2925] (ping,
traceroute and lookup operations). Also, the ability to define
constructor/destructor interfaces could address issues such as
encountered with SNMP's RowStatus solution.
Notes: Is it possible to do methods without changing the underlying
protocol? There is agreement that methods are useful, but
disagreement upon the impact - one end of the spectrum sees this
as a documentation tool for existing SNMP capabilities, while the
other end sees this as a protocol update, moving forward, to
natively support methods. The proposal is to wait and see if this
is practical to implement as a syntax that is useful and can map
to the protocol.
4.2.2 Unions
Number: 32
Type: should
From: WG
Description: SMIng should support a standard format for unions.
Motivation: Allows an attribute to contain one of many types of
values. Allows related attributes to be grouped together. The
lack of unions has also lead to relatively complex sparse table
work-around in some DISMAN mid-level managers.
Notes: The thought is that SNMP and COPS-PR can already support
unions because they do not care about what data type goes with a
particular OID.
Elliott, et. al. Expires December 11, 2001 [Page 18]
Internet-Draft SMIng Requirements June 2001
4.2.3 Abstract vs. Concrete Structures
Number: 35
Type: new
From: NMRG, WG
Description: SMIng should differentiate between abstract and concrete
grouping of attributes (structures).
Motivation: This information gives people more information how
structures can and should be used. It hinders them from misusing
abstract structures.
Notes: There is general confusion regarding the usefulness of
abstract from the data point of view.
This requirement attempted to convey the idea that some structures
are not meant to stand on their own and instead only make sense if
contained within another structure. The term abstract, which
itself carries some connotation from the object-oriented world,
may not be the best term to use.
4.2.4 Float Data Types
Number: 49
Type: new
From: WG, NMRG
Description: SMIng should support the base data types Float32,
Float64, Float128.
Motivation: Missing base types can hurt later on, because they cannot
be added without changing the language, even as an SMIng
extension. Lesson learnt from the SMIv1/v2 debate about
Counter64/Integer64/...
Notes: There is no mention as to whether or not the underlying
protocols will have to natively support float data types. This is
left to the mapping. However, it seems imperative that the float
data type needs to be added to the set of intrinsic types in the
SMIng language at the creation of the language as it will be
impossible to add them later without changing the language.
4.2.5 Comments
Number: 59
Type: should
From: NMRG
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 been
a constant source of confusion. People use arbitrary lengthy
strings of dashes (`-----------') in the wrong assumption that
Elliott, et. al. Expires December 11, 2001 [Page 19]
Internet-Draft SMIng Requirements June 2001
this is always treated as a comment. Some implementations try to
accept these syntactically wrong constructs which even raises
confusion. We should get rid of this problem.
Notes: If the SMIng working group adopts a C-like language, then the
C++/Java single-line comment should be adopted as well.
4.3 Rejected Requirements
This section represents the list of requirements that were rejected
because they either were deemed unnecessary, too complicated, outside
the scope of the WG charter, or no-brainers.
4.3.1 Incomplete Translations
Number: 10
Type: basic
From: WG
Description: 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: SMIng working group requires this to ease transition.
Notes: Deemed not a valuable use of the working group's time.
4.3.2 Instance Naming
Number: 11
Type: align
From: SMI, SPPI
Description: Instance naming is subject of the protocol mappings and
not part of the protocol-neutral model. INDEX, PIB-INDEX must be
accommodated.
Motivation: COPS-PR and SNMP have different instance identification
schemes that must be aligned in the protocol specific mappings.
Notes: This requirement is not being rejected because it is a bad
idea. It is rejected because MIBs and PIBs are sufficiently close
to allow one specification, in the protocol-neutral model, for
both.
4.3.3 Attribute Value Constraints
Number: 44
Type: new
From: WG
Description: SMIng must provide mechanisms to formally specify
constraints between values of multiple attributes.
Motivation: Constraints on attribute values [occur] where one or more
attributes may affect the value or range of values for another
Elliott, et. al. Expires December 11, 2001 [Page 20]
Internet-Draft SMIng Requirements June 2001
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 requirement as 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 requirements.
4.3.4 Existence Constraints
Number: 41
Type: new
From: WG
Description: SMIng must provide a mechanism to formally express
existence constraints.
Motivation: Existence constraints are already embedded in SMIv2 INDEX
clauses and DESCRIPTION clauses.
Notes: The conclusion is that it is better to avoid explicit fate
sharing and cover this with a description clause. Individual
requirements (e.g., inheritance (Section 4.1.31), containment
(Section 4.1.30), arrays (Section 4.1.25), etc.) that implicitly
provide existence constraints have stated so in their
requirements.
4.3.5 Ordering Constraints
Number: 42
Type: new
From: WG
Description: SMIng must provide a mechanism to formally express
ordering constraints.
Motivation:
Notes: It is not clear why this cannot be done in the description
clause.
4.3.6 Attribute Transaction Constraints
Number: 43
Type: new
From: WG
Description: SMIng must 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: Alternative is to either use Methods (Section 4.2.1) or assume
Elliott, et. al. Expires December 11, 2001 [Page 21]
Internet-Draft SMIng Requirements June 2001
that all attributes in a structure (Section 4.1.29) are to be
considered atomic.
4.3.7 Method Constraints
Number: 47
Type: new
From: WG
Description: Method definitions must provide constraints on
parameters.
Motivation:
Notes: Unless methods (Section 4.2.1) are done, there is no use for
this.
4.3.8 Categories
Number: 28
Type: basic
From: SPPI
Description: SMIng must provide mechanisms to group definitions into
subject categories. Concrete instances may only exist in the
scope of a given subject category or context.
Motivation: To scope the categories to which a module applies. In
SPPI this is used to allow a division of labor between multiple
client types.
Notes: This requirement is specific to COPS-PR and therefore does not
have general applicability and may complicate matters as SNMP
won't have much use for it.
4.3.9 Agent Capabilities
Type: basic
Number: 29
From: SMI
Description: SMIng must provide mechanisms to describe agent
implementations.
Motivation: To permit manager to determine variations from the
standard for an implementation.
Notes: Agent capabilities should not be part of SMIng, but should
instead be a separate capabilities table.
4.3.10 Relationships
Number: 36
Type: new
From: NMRG, WG
Description: Ability to formally depict existence dependency, value
dependency, aggregation, containment, and other relationships
Elliott, et. al. Expires December 11, 2001 [Page 22]
Internet-Draft SMIng Requirements June 2001
between attributes or groupings of attributes.
Motivation: Helps humans to understand the conceptual model of a
module. Helps implementers of MIB compilers to generate more
`intelligent' code.
Notes: This requirement was deemed too general to be useful and
instead the individual types of relationship requirements (e.g.,
pointers, inheritance, containment, etc.) are evaluated on a case-
by-case basis with the specific relationships deemed useful being
included as accepted requirements.
4.3.11 Procedures
Number: 38
Type: new
From: WG
Description: SMIng should support a mechanism to formally define
procedures that are used by managers when interacting with an
agent.
Motivation:
Notes: Best to do this in the description clause.
4.3.12 Associations
Number: 45
Type: new
From: WG
Description: SMIng should provide mechanisms to explicitly specify
associations.
Motivation:
4.3.13 Association Cardinalities
Number: 46
Type: new
From: WG
Description: Cardinalities between associations should be formally
defined.
Motivation: If you have an association between structures 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 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.12), this has no use.
Elliott, et. al. Expires December 11, 2001 [Page 23]
Internet-Draft SMIng Requirements June 2001
4.3.14 Categories of Modules
Number: 51
Type: new
From: Individual
Description: The SMIng documents should give clear guidance on which
kind of information (with respect to generality,
type/structure/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 ensures
that generally useful definitions do not go into device or service
specific modules.
Motivation: Bad experience with SMIv2.
Notes: It is not clear how this can be done with the language to be
created by SMIng WG. It could be analogous with header files,
however there is potentially lots of process associated with doing
this. There may be a better way to create TCs that are used by
many.
4.3.15 Length of Identifiers
Number: 53
Type: should
From: NMRG
Description: The allowed length of the various kinds of identifiers
should be extended from the current `should not exceed 32' (maybe
even from the `must not exceed 64') rule.
Motivation: Reflect current practice of definitions.
Notes: Not clear what value this provides, so decision was to keep
things as is.
4.3.16 Why Are So Many SMIv1/v2 Parsers So Error Tolerant?
Number: 54
Type: should
From: Individual
Description: It should be clearly stated that parser implementations
which accept input that does not conform to the SMIng language
rules are not compliant.
Motivation: SMIv1/v2 parsers are tolerant, because MIB editors do not
get SMI right, because it builds on hardly available obsolete
ASN.1 CCITT specifications. With SMIng there is a chance to get
the syntax clearly and self-contained defined, so that there is no
Elliott, et. al. Expires December 11, 2001 [Page 24]
Internet-Draft SMIng Requirements June 2001
excuse for errors and parser implementations become more
consistent. (Who would expect that a C compiler is tolerant about
a missing semicolon?)
Notes: This requirement appears to be in conflict with language
extensibility (Section 4.1.6).
4.3.17 Core Language Keywords vs. Defined Identifiers
Number: 55
Type: should
From: NMRG
Description: In SMIv1/v2 things like macros or some(!) types have to
be imported from SMI modules. People are continuously confused
about what has to be imported (imagine if `typedef' would have to
be #included in a C program) and what the difference between those
SMI modules and usual modules is.
Motivation: Reduce confusion. Clarify the set of language keywords.
Notes: This requirement was not rejected because it was a bad idea.
Instead, it was rejected as it was thought that it is basic enough
of an idea that it's a no-brainer. The assumption can be made
that any keywords defined in the SMIng language will not have to
be imported.
4.3.18 Internationalization
Number: 56
Type: new
From: Individual
Description: Informational text (DESCRIPTION, REFERENCE, ...) should
allow i18nized encoding (UTF8? others?).
Motivation: There has been some demand for i18n in the past.
Notes: English is the language of the IETF and therefore it is not a
requirement of the SMIng language must allow i18n.
4.3.19 Mapping Modules to Files
Number: 58
Type: new
From: NMRG
Description: There should be a clear statement how SMIng modules are
mapped to files (1:1, n:1?) and how files should be named (by
module name in case of 1:1 mapping?).
Motivation: SMI implementations show up a variety of filename
extensions (.txt, .smi, .my, none). Some expect all modules in a
single file, others don't. This makes it more difficult to
exchange modules.
Notes: This is just an implementation detail and is best left to a
BCP and not made a part of the language definition.
Elliott, et. al. Expires December 11, 2001 [Page 25]
Internet-Draft SMIng Requirements June 2001
4.3.20 Simple Grammar
Number: 60
Type: new
From: NMRG
Description: The grammar of the language should be as simple as
possible. It should be free of exception rules. A measurement of
simplicity is shortness of the ABNF grammar.
Motivation: Ease of implementation. Ease of learning/understanding.
Notes: This seems like an obvious requirement, however shortness of
the ABNF grammar is not necessarily a reflection of the simplicity
of the language. The WG will do the right thing with regard to
defining the language for SMIng.
4.3.21 Place of Module Information
Number: 61
Type: should
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 does not seem to be a problem with the current SMI and is
dropped for simplicity.
4.3.22 Fully Qualified Identifiers
Number: 62
Type: should
From: NMRG
Description: To reference multiple identifiers with the same name but
imported from multiple modules a qualifying mechanism, e.g.,
`module::name', is needed. It should be manifested in the
grammar. (SMI and SPPI do support it already because of their
ASN.1 derivation, but many implementation fail to handle this
correctly.)
Motivation: Unambiguous references to identifiers.
Notes: Look at existing requirements for SMI and SPPI. Adding
another requirement to SMIng for something that is already a
requirement adds no value.
4.3.23 Readable Revision Date Representation
Number: 63
Type: should
From: NMRG
Description: The SMI notation of revision dates consists of 11 or 13
Elliott, et. al. Expires December 11, 2001 [Page 26]
Internet-Draft SMIng Requirements June 2001
characters, e.g. 199602282155Z, which is difficult to parse for
humans. The trailing `Z' which represents GMT is superfluous,
since no other time zone is allowed.
SMIng should support a nicer notation, e.g. based on ISO 8601
representation: 1996-02-28 21:55 or simply 1996-02-28 since time
information is not relevant in almost any case.
Motivation: SMIng should support a nicer notation, Human readability
of date and time information.
Notes: There is no reason to make more complicated rules unless the
syntax of the date string is to be changed completely.
4.3.24 Make Status Information Optional
Number: 64
Type: new
From: NMRG
Description: SMI and SPPI definitions must have a status information
(current, obsolete, deprecated). SMIng should make the status
clause optional with a default of `current'.
Furthermore, clear statements are required on constraints of
status information of related definitions, e.g., a current
attribute definition must not make use of an obsolete defined
type, etc. Note, that this is problematic with definitions from
multiple independently evolving modules.
Motivation: Make definitions more compact. Hide redundant
information.
Notes This represents an insignificant change that just adds one more
rule to follow.
4.3.25 Remove OIDs from the Core Language
Number: 67
Type: new
From: NMRG
Description: While in SMI and SPPI definitions of attributes are
bound to OIDs, SMIng should not use OIDs for the definition of
structures, structure attributes, events, etc. Instead, SNMP and
COPS-PR mappings should assign OIDs to the mapped items.
Motivation: OIDs of synonymous attributes are not the same in SMI and
SPPI definitions. Hence, they must not appear in protocol neutral
definitions.
Notes: Since both COPS-PR and SNMP both use OIDs, why not just align
them. Clearly, structures and TCs should not contain OIDs, which
is already true. The only problem with OIDs is that a structure
(Section 4.1.29) cannot be reused if an OID is assigned at that
level. The solution is the reusable components (e.g., structures)
Elliott, et. al. Expires December 11, 2001 [Page 27]
Internet-Draft SMIng Requirements June 2001
need not have OID numbers, while non-reusable components (e.g.,
tables) can have OIDs.
4.3.26 Module Namespace
Number: 68
Type: new
From: WG
Description: Currently the namespace of modules is flat and there is
no structure in module naming causing the potential risk of name
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 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 risk of module name clashes.
Notes: Some aspects of this requirement overlapped with other
requirements and other aspects were thought best left to a BCP.
4.3.27 Hyphens in Identifiers
Number: 72
Type: should
From: NMRG
Description: There has been some confusion whether hyphens are
allowed in SMIv2 identifiers: Module names are allowed to contain
hyphens. Node identifiers usually are not. But for example `mib-
2' is a frequently used identifier that contains a hyphen due to
its SMIv1 origin, when hyphen were not disallowed. Similarly, a
number of named numbers of enumeration types contain hyphens
violating an SMIv2 rule.
SMIng should simply allow hyphens in all kinds of identifiers. No
exceptions.
Motivation: Reduce confusion and exceptions. Requires, however, that
implementation mappings properly quote hyphens where appropriate.
Notes: Since nobody is currently complaining about the hyphen
problem, there is no reason to fix it. The restriction on "_"
(underscore) should be relaxed.
4.3.28 Referencing a Group of Instances of a Structure
Number: 75
Type: align
Elliott, et. al. Expires December 11, 2001 [Page 28]
Internet-Draft SMIng Requirements June 2001
From: Individual
Description: PIB and MIB row attributes reference a group of entries
in another table. This semantic needs to be formalized.
Motivation: SPPI formalizes this feature using TagId and
TagReferenceId semantics in the DiffServ PIB. SMI also uses these
semantics without any formal notation (see SNMP-TARGET-MIB in
RFC2273).
Notes: There are no issues with the requirement, but instead with how
this is mapped cleanly and more generally. Effectively, this is a
constraint clause that specifies the table and column that
contains a value used for grouping. This can be mapped to
EXPANDS, which would have to be added to SPPI.
5. Security Considerations
This document defines requirements for a language with which to write
and read descriptions of management information. The language itself
has no security impact on the Internet.
6. Acknowledgements
Thanks to Dave Durham, whose work on the original NIM (Network
Information Model) draft was used in generating this document.
Thanks to Frank Strauss for maintaining the web site that was home
for the requirements list during the requirements discussion period.
Thanks to Andrea Westerinen for her contributions on the original NIM
and SMIng drafts.
References
[1] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple
Network Management Protocol (SNMP)", STD 15, RFC 1157, May
1990.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
McCloghrie, K., Rose, M. and S. Waldbusser, "Structure of
Management Information Version 2 (SMIv2)", STD 58, RFC 2578,
April 1999.
[4] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
McCloghrie, K., Rose, M. and S. Waldbusser, "Textual
Conventions for SMIv2", STD 58, RFC 2579, April 1999.
Elliott, et. al. Expires December 11, 2001 [Page 29]
Internet-Draft SMIng Requirements June 2001
[5] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance
Statements for SMIv2", STD 58, RFC 2580, April 1999.
[6] McCloghrie, K., Case, J., Rose, M. and S. Waldbusser,
"Management Information Base for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1907, January 1996.
[7] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax Definitions",
RFC 2252, December 1997.
[8] White, K., "Definitions of Managed Objects for Remote Ping,
Traceroute, and Lookup Operations", RFC 2925, September 2000.
[9] 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.
[10] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, S.,
Sahita, R., Smith, A. and F. Reichmeyer, "Structure of Policy
Provisioning Information (SPPI)", draft-ietf-rap-sppi-06.txt,
April 2001.
[11] Fine, M., McCloghrie, K., Seligson, J., Chan, K., Hahn, S.,
Sahita, R., Smith, A. and F. Reichmeyer, "Framework Policy
Information Base", draft-ietf-rap-frameworkpub-04.txt, April
2001.
[12] Strauss, F., Schoenwaelder, J. and K. McCloghrie, "SMIng - Next
Generation Structure of Management Information", draft-irtf-
nmrg-sming-04.txt, November 2000.
Authors' Addresses
Chris Elliott
Cisco Systems
7025 Kit Creek Road
Research Triangle Park, NC 27709
USA
EMail: chelliot@cisco.com
Elliott, et. al. Expires December 11, 2001 [Page 30]
Internet-Draft SMIng Requirements June 2001
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
Bueltenweg 74/75
38106 Braunschweig
Germany
EMail: schoenw@ibr.cs.tu-bs.de
URI: http://www.ibr.cs.tu-bs.de/
Frank Strauss
TU Braunschweig
Bueltenweg 74/75
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.com
Elliott, et. al. Expires December 11, 2001 [Page 31]
Internet-Draft SMIng Requirements June 2001
Appendix A. Mailing List Discussions
o Human Readability (Section 4.1.3):
* Jamie: One thing I have noticed reading the IPsec PIB and MIB
documents is that the semantics of the model being presented
are easily lost. The reason this is important to me is as a
co-author on the IPsec policy model, I want to make sure that
the PIB and MIB are semantically equivalent to the policy model
so that they represent the same information. Parsing through
the SMI and SPPI to understand the semantics of the particular
derivation for me is excruciatingly painful. I think that a
language that is more akin to C would make that human parsing
of the PIB/MIB much easier. As it stands now, I am relegated
to drawing pictures of the tables in order to understand what
is going on.
* Todd A Anderson: I would highly prefer a C-like syntax (or a
CORBA IDL-like syntax given than CORBA IDL is similar to C-like
syntax) to an ANS1-like syntax. I think that C-like syntax is
clearer and more straight-forward.
* David Putzolu in consequence of his comments on #37 and #45-46:
Finally, if I were brave enough to try to satisfy the above
mentioned requirements in SMIng, doing so and expressing the
relevant syntax in ASN.1 sounds extremely painful - if we must
go down this path, lets do it using something C++, or Java-like
- that would at least give a syntactic foundation that is
relevant to writing a programming language.
o Instance Pointers (Section 4.1.19):
* Jamie: It is common when data modeling to reference another
object instead of embedding the referenced object inside of the
object doing the referencing. This is also important as it
allows objects to have independent lifetimes as well as be
referenced by many objects.
* Jamie: Can someone please elaborate on the differences between
#14 (Instance Pointers) and #15 (Row Pointers). Can they be
thought of in this way? Instance pointers are typed pointers,
whereas row pointers are void pointers. With the distinction
being that an instance pointer may only reference a row in one
type of table, while a row pointer may reference a row in any
kind of table?
* Juergen: I think the terms are used as defined in RFC 2579
(InstancePointer and RowPointer). The RowPointer always points
to an instance of a row while the InstancePointer can also
point to a particular cell in a table. Note that this has
nothing to do with a typed pointer (a concept which does not
really exist in SMIv2). SPPI however has ways to type pointers
- that is to restrict them so that they can not point to
everything.
(Using a class-based terminology, the difference is whether we
Elliott, et. al. Expires December 11, 2001 [Page 32]
Internet-Draft SMIng Requirements June 2001
are done with supporting pointers to class instances or whether
we also need pointers to concrete attributes of class
instances.)
o Accessibility (Section 4.1.5):
* Frank: To some degree accessibility might depend on the
protocol. Creation/deletion information might be protocol
dependent(?). `Accessible for notify' might be protocol
dependent(?). Do we need `write-only'?
* Robert Story: There is a recent thread over in the SNMPv3 list
in this vein. Someone asked what they should return for a set-
able password object: asterisks, empty string, NULL, etc. A
syntax of write-only would help in this case.
* David H.: Row creation/deletion is a fundamental feature of
SMIv2 and is required for backward compatibility and
interoperability. Accessible-for-notify is a feature of SMIv2
and must be supported for backwards compatibility and
interoperability.
* David Perkins: Row creation/deletion is not really part of the
SMI except for the status of read-create. Otherwise, the SMI
is blissfully ignorant of creation and deletion. You may claim
that the RowStatus TC makes creation and deletion part a
fundamental feature. If so, I disagree, since the SMI does not
require one to use the RowStatus TC for creation/deletion and
when RowStatus is used, there is nothing special about the
table and columns that use it.
* David Perkins: On status accessible-for-notify, this is a
status value whose usage and interpretation has been twisted
since its creation and is abused in almost every case where it
is used. It increases the difficulty of testing, and can
easily result in errors that show up only during exceptional
situations.
* Frank: Let's be precise: Not creation/deletion is a feature of
SMIv2, but a notation that allows to express whether a table
allows creation/deletion of instances through protocol
operations. I agree that both, create/delete information and
accessible-for-notify information, is required in SMIng, but
I'm not sure whether we need it in the protocol neutral or in
the protocol dependant parts.
o Creation/Deletion (Section 4.1.33):
* Frank: Let's not mix up protocol operations and the data model.
SMI does not have what this issue demands and IMHO this issue's
status should be `new' instead of `basic'.
* David H.: draft-ietf-rap-sppi-06.txt has Install-ERRORS as part
of the SPPI grammar. Both SMI and SPPI discuss "read-create".
rfc2079.txt discusses using the MAX-ACCESS clause to indicate
whether it makes protocol sense to create an instance of an
object. As I see it, both recognize the need to be able to
create "things" in the protocol. RFC2079 has the RowStatus T-C
Elliott, et. al. Expires December 11, 2001 [Page 33]
Internet-Draft SMIng Requirements June 2001
which explicitly discusses how to delete a "thing" in the
protocol. SPPI, in the description of the ReferenceID,
explicitly discusses deleting an instance of a PRI. All of
these discussions of creation/deletion are found in the
SMI/SPPI documents, not in the SNMP or COPS-PR protocol
documents.
* Frank: Ok. So the first sentence of this requirement's
description should be reworded to something like: SMIng should
support a mechanism to define whether creation/deletion
protocol operations for instances would make sense. This is
already covered by issue #17.
o Categories (Section 4.3.8)
* Jamie: Is this akin to C++ namespaces (apologies to those who
are not familiar with them) in that they allow for scoping in
order to reduce/prevent name collisions? Or, is this the
purpose of #68 (Module Namespace)? If #68 serves this purpose,
I would like some more clarification on #28 so that I can get
them straight in my mind.
* Juergen: This #28 is not about C++ namespaces. Categories are
a way to categorize definitions - e.g. all the definitions
relevant for a diffserv manager or all the definitions relevant
for the security manager. COPS-PR and SPPI have this concept.
The SNMP world sometimes uses contexts to achieve something
similar. I once had a long debate with Keith about the
difference between contexts and subject categories and I am
still confused about it. ;-)
o Agent Capabilities (Section 4.3.9)
* Frank: Capability statements in MIB modules are hardly useful
to managers, since in most cases they are simply not available.
Agent capabilities should be retrievable at runtime from the
agent itself through something like a capabilities MIB. Hence,
I suggest to drop `agent capabilities' from the core SMIng
language.
* Jamie: I would like to second the idea that #29 (Agent
Capabilities) be removed from the SMIng requirements. This
does not seem to belong at this level.
o Deprecate Use of IMPLIED Keyword (Section 4.1.37):
* Frank: The SNMP mapping must keep IMPLIED for compatibility.
But it should be clearly stated that it must not be used in
newly defined SNMP mappings.
o Classes (Section 4.1.29):
* Jamie: I agree with the motivation - I think it is a good thing
to be able to group attributes together for reuse. However, I
am wondering if the name classes can be changed to something
more generic. I don't know if "structures" are any better, but
I would like to see a different description.
* Jamie later on: Would it be possible to name #33 (Classes) to
something like "Attribute Groups"?
Elliott, et. al. Expires December 11, 2001 [Page 34]
Internet-Draft SMIng Requirements June 2001
* Juergen: Fine with me.
* David Putzolu: Methods are strongly associated with classes in
the programming language lexicon, so choosing a different name
is a good idea.
* David D.: How about Attribute Class or aclass for short? Given
your comment to #34 below, I think the word "class" implies
inheritance abilities, whereas Attribute Groups, Structures,
etc. do not.
o Single Inheritance (Section 4.1.31):
* Frank: I strongly suggest to decide whether this is a
requirement after a few examples are found including their
mappings to SNMP and COPS-PR tables! If we look at the example
above, each inherited scheduler would have to remain a
scheduler whose instances all appear in a common scheduler
table. Thus the mapping to SNMP should lead to a basic table
that holds all common attributes (the parent class?) and a
number of table augmentations. Currently, I see now way how
inheritance could help in this situation. Cut&paste is not
needed. Table relationships are the key.
* Frank: Another motivation: inheritance could help to add
attributes to a class that are specific to certain protocol
mapping and do not appear in the protocol neutral module.
E.g., RowStatus attributes in SNMP mappings.
* Jamie: I see this important because as more WGs move to data
modeling, it is natural to model using OO methodologies. For
example, in the IPsec Policy WG we are modeling the IPsec
configuration policy (draft-ietf-ipsp-config-policy-model-
02.txt), which derives from the Policy Core Information Model
from the Policy Framework WG. Both are modeled using OO
methodology and make extensive use of single inheritance. In
addition to the abstract model, the WG is defining a PIB
(draft-ietf-ipsp-ipsecpib-02.txt) and a MIB (draft-ietf-ipsp-
ipsec-conf-mib-00.txt) as concrete instantiations of the
abstract model.
* David Putzolu: As long as we avoid methods, ctors/dtors,
exceptions, etc., then single inheritance is not only useful
but feasible as well.
o Abstract vs. Concrete Classes (Section 4.2.3)
* Jamie: When doing data modeling using OO methodologies, it is
important to be able to define an abstract class, which
contains some set of attributes common to all derived classes,
but which is never meant to be instantiated by itself. Again,
an example is the IPsec policy configuration model - in that
model, we have the idea of an IPsec transform. There are
current three transforms in the model - AH, ESP, and IPCOMP.
All three share a set of attributes. Instead of repeating the
definitions of these attributes in each derived class, the
attributes are defined in an abstract base class and all three
Elliott, et. al. Expires December 11, 2001 [Page 35]
Internet-Draft SMIng Requirements June 2001
derive from the abstract base class.
o Methods (Section 4.2.1)
* David Putzolu: If I define a class (attribute grouping?) that
derives from an abstract class, and the abstract class defines
a method with a return value of one type, but my newly defined
class has a method of the same name but returns another type,
which one is invoked? Questions like this worry me - but I can
probably answer this question if the language being used is C++
or Java. However, the goal is not to do all the things that
C++ or Java does (come up with a programming language) - it is
to make a modeling language. As such, on requirement #37 I
strongly agree with Juergen when he wrote, "I prefer to stay
away from methods at this point in time (but make the language
extensible so they might be added later)."
* Juergen: The WG charter says that we do a "next generation data
definition language for specifying network management data".
We are not supposed to create a generic (information) modeling
language. My argument for postponing methods is based on the
observation that SNMP as well as COPS currently do not support
method invocation natively and so you either have a feature in
the data definition language which you can't use in practice
(at least with SNMP and COPS-PR) or you have to do really ugly
things to emulate generic method calls on top of what SNMP and
COPS provides you.
The issue of naming scopes and how you resolve conflicts is
important. But I do not think it is very complex to handle
this nor do I think that specifying how you solve name
conflicts makes the data definition language a programming
language. We already have rules in the SMIv2/SPPI how to
resolve conflicts if you have to import definitions with
similar names. If we have methods, we sure need more rules -
but nothing conceptually very different.
* David Putzolu again on #37 revisited: If we were to do methods,
that of course leads to the idea of exceptions. Exceptions are
a great tool for writing high quality software for a number of
reasons - but I have no clue how they relate to the case of a
data modeling language that will be mapped to on-the-wire SNMP
and COPS PDUs. How would I map a try..catch block or a throw()
to a SNMP PDU? What meaning does the idea of passing an
unhandled exception on to a higher execution context (stack
unrolling) have to a DECision message? I strongly suggest that
if methods are done that exceptions not be done. If methods
are not done, the question of exceptions becomes moot.
* Juergen: Exceptions model exceptional conditions that can
happen on the "agent" while you invoke a "method". A good
example are the INSTALL-ERRORS in the SPPI which enumerate the
exceptions that can happen while creating a new row via COPS-
Elliott, et. al. Expires December 11, 2001 [Page 36]
Internet-Draft SMIng Requirements June 2001
PR. Note that this notion of exceptions is completely
independent from the way an application written in a particular
programming language processes exceptions. The try...catch
block is a programming language construct and we are of course
not going to specify this.
If you want an example how this can work, then please take a
look at the CORBA world. The CORBA folks define exceptions at
the IDL level. The programming language binding later says how
things are mapped to programming language constructs. And the
mappings look very different, depending on whether you use C or
Java.
o Arrays (Section 4.1.25):
* Juergen: It is unclear what this really means. Does an array
imply atomic access to the whole array? Or is it sufficient to
say this is just a short-cut for another expanding table?
* Andrea: I had viewed this only as allowing a multi-valued
attribute, not as arrays of multiple attributes. This needs to
be clarified.
* Todd A Anderson: I prefer the IDL verbiage of "sequence"
instead of array since array implies something of fixed length
to me. I think that sequences are a necessary part of SMIng
since I am constantly frustrated by the proliferation of tables
I have to create to simulate sequence semantics. It seems to
me that without sequences, the number of associations would
also have to increase. I think it is just clearer and more
natural for those with a programming background to think of
sequences of data instead of breaking up the data structure
into multiple locations.
* Jamie: Is this as Andrea thought (a multi-valued attribute), or
is it a set of multiple attributes? I can see use for having a
set of multiple attributes (which is what I had thought it
was).
* Juergen: My understanding is that this refers to a multi-valued
attribute.
o Ordering Constraints (Section 4.3.5)
* Frank: What does this mean?
* Andrea: At least in some of the discussions, this "requirement"
went hand in hand with #43 (transaction constraints). IE, if
you modify something "in combination", the changes may need to
occur in a specific order (first attribute A, then attribute
B).
o Attribute Transaction Constraints (Section 4.3.6)
* Todd A Anderson: Could someone provide some clarity on issues
#42 and #43? An issue that seems similar to #43 is the case
when sometimes I want to execute several table changes
atomically but other times I may not want to make those changes
atomically. Is the language an appropriate place to deal with
Elliott, et. al. Expires December 11, 2001 [Page 37]
Internet-Draft SMIng Requirements June 2001
this sort of behavior? Are there any modeling issues related
to this sort of transaction? My instinct is that there isn't
for this type of transaction but for the case where you must
always change several things atomically then the language is an
appropriate place to state that. How would the other type of
transaction be handled then?
o Associations (Section 4.3.12)
* Frank: What does this mean? Aren't relationships (issue #36)
the same?
* Andrea: Yes, an association is a kind of relationship but has
additional info like cardinality on the related entities.
Relationships include inheritance.
* David Putzolu on #45 and #46: These are two more ideas that on
their own make good sense, but seem to complicate the big
picture. How would cardinality be captured in a mapping to
SNMP or COPS? Pointers seems pretty easy to map to these
protocols - but where does associations fit in? These two are
elegant tools, but I think in this context, since we already
have pointers, and two pointers in a table can model an
association, simplicity says remove these two requirements.
o Association Cardinalities (Section 4.3.13)
* See also David Putzolu's comment on issue #45.
o Float Data Types (Section 4.2.4)
* Todd A Anderson: I am glad to see that the spec includes float
data types in the language. I find these types especially
useful for TSPECs and fractional link bandwidth partitioning.
o Why Are So Many SMIv1/v2 Parsers So Error Tolerant? (Section
4.3.16)
* David H.: I think the reality of the situation is that
developers write few mibs, but write much C code. There are
few developers who understand mib syntax, and I don't expect to
see that improve even if we use a non-ASN.1 language, and
parsers are classified as non-compliant. I won't oppose this
suggestion, but I doubt it will solve the problem.
* Frank: If parsers are (available and) forced to be verbatim
about errors then MIB authors have simple tools to validate
their modules. C programs are correct because they must be
compiled to be useful and because C compilers are strict. I
agree, that many people are not really familiar with MIB syntax
because they write much less MIB modules than C (or other)
code. And I agree that a non-ASN.1 looking syntax would not
help significantly.
o Internationalization (Section 4.3.18)
* David H.: Fred Baker made it very clear as IESG chair that all
documents submitted for standards advancement should be done in
English to ensure a large enough body of reviewers exists to
provide industry-wide review.
Elliott, et. al. Expires December 11, 2001 [Page 38]
Internet-Draft SMIng Requirements June 2001
I fear making mib descriptions i18n capable would encourage
development of mibs written in languages that most developers
could not read, and that would hurt interoperability.
I understand that it is frustrating for those who do not speak
English as their primary language to be forced to use English.
However, the purpose of standards is to improve
interoperability.
* Randy: Many MIBs are never subjected to the standards process.
A specification should be intelligible to the community of
developers and users that will use that MIB. Many MIBs never
see use outside the organizations that defined them.
Let the RFC submission / publication process do its job of
weeding out horrible things like the name of the city where I
live, and tricky things like non-English words and phrases that
fit into seven-bit ASCII. We don't have to replicate that
service in our language definition, just as our language
definition doesn't need to recapitulate the I-D and RFC rules
for page breaks.
We are not doing the world a service by preventing
organizations from using the tools we define to develop
specifications that their developers can understand.
o Mapping Modules to Files (Section 4.3.19)
* David H.: I think this is two separate requirements with
different potential effects on the community and should be
described separately.
I have no issue with deciding that there should only be one
module per file, or that more than one can be bundled together.
(I prefer the single module per file to make updates easier)
I am concerned that requiring specific filename formatting may
prevent files from being used on some operating systems. I
gladly accept that the documents should recommend, but not
require, a consistent format for naming mib files. But I would
consider it a bad thing to have a compiler refuse to compile a
mib because the filename doesn't match the mib name, or
whatever.
o Place of Module Information (Section 4.3.21)
* David H.: I don't understand what is being requested here. Is
the (like SMIv2 MODULE-IDENTITY) and example if what is
desired, or an example what is not desired? Where does module
information belong in the proposer's eyes?
* Frank: I'm sorry for the confusion. I try to be more precise:
In SMIv2 and SPPI the MIB/PIB author has to put some module
meta information in a specific macro (MODULE-IDENTITY) which is
Elliott, et. al. Expires December 11, 2001 [Page 39]
Internet-Draft SMIng Requirements June 2001
registered with an OID although this registration is not useful
for any purpose. The proposal is to let SMIng (a) not register
module meta information in the registration tree and (b) not
introduce a new macro/statement wrapping the module meta
information, since the module itself is the appropriate
container.
o Make Status Information Optional (Section 4.3.24)
* David H.: I believe this is a bad idea if we allow inheritance
and independent evolution of modules. It is very possible that
a base class could be declared obsolete, but the derived
classes would still incorrectly default to current. Some might
conclude that they cannot obsolete something that somebody
might have derived from, so they leave it marked as current.
I think defaulting to current will be very confusing to people
and the cure is worse than the illness. We need to make our
standards unambiguous, much more than we need to eliminate a
little redundancy.
* Frank: Status information w.r.t. inheritance is a general
problem as already stated in the description section. It does
not matter whether the status clause is optional with a well
defined default status if absent or whether the status clause
is mandatory. There is no problem of ambiguity.
* Jamie: Am I right in assuming that #64 (Make Status Information
Optional) refers to status information that is most useful to a
human? For example, if something is deprecated, a compiler
could inform the user that they are depending on/deriving
from/referencing something that has been deprecated in a manner
similar to how the Java compiler does. If we go down the path
of keeping the status information for the purpose of providing
meaningful information from compilers, do we go down the road
of also supplying additional information. For example, in the
case of a deprecated class that is inherited from, should there
also be information that states the name of the new class that
should be inherited from instead?
* Juergen: Issue #64 only deals with the proposal to make the
status statement in the language optional in order to make
definitions more compact and easier to read for humans. Issue
#64 does not propose to change the semantics of the status
values as they are used in the SMIv2 or the SPPI.
What compilers do with the status values is implementation
specific. Sure, a good compiler should warn if current
definitions depend on deprecated or obsolete definitions. I
personally would leave it to the MIB authors who deprecates
definitions to explain the situation in the description clause.
I personally prefer to not add language complexity in this case
as the benefit does not seem clear/convincing to me.
Elliott, et. al. Expires December 11, 2001 [Page 40]
Internet-Draft SMIng Requirements June 2001
o Allow Refinement of All Definitions with Conformance Statements
(Section 4.1.40):
* David H.: I am not aware that this has been a problem except
for one person. I am concerned that the requested requirement
be that "All Definitions" must be allowed to be refined rather
than to request that the one specific problem be addressed.
o Referencing a Group of Instances of a Class (Section 4.3.28)
* David H.: Is this already covered by #46 Association
Cardinalities? Do we need to separate the formal specification
of cardinality from its use here for associations?
Elliott, et. al. Expires December 11, 2001 [Page 41]
Internet-Draft SMIng Requirements June 2001
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.
Elliott, et. al. Expires December 11, 2001 [Page 42]
