rfc3216.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,852 行 · 第 1/4 页
TXT
1,852 行
Network Working Group C. Elliott
Request for Comments: 3216 Cisco Systems
Category: Informational D. Harrington
Enterasys Networks
J. Jason
Intel Corporation
J. Schoenwaelder
F. Strauss
TU Braunschweig
W. Weiss
Ellacoya Networks
December 2001
SMIng Objectives
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document describes the objectives for a new data definition
language, suitable for the modeling of network management constructs,
that can be directly mapped into SNMP and COPS-PR protocol
operations.
The purpose of this document is to serve as a set of objectives that
a subsequent language specification should try to address. It
captures the results of the working group discussions towards
consensus on the SMIng objectives.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Specific Objectives for SMIng . . . . . . . . . . . . . . 4
4.1 Accepted Objectives . . . . . . . . . . . . . . . . . . . 5
4.1.1 The Set of Specification Documents . . . . . . . . . . . . 6
4.1.2 Textual Representation . . . . . . . . . . . . . . . . . . 6
4.1.3 Human Readability . . . . . . . . . . . . . . . . . . . . 6
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 and
Attributes . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.25 Table Existence Relationships . . . . . . . . . . . . . . 13
4.1.26 Table Existence Relationships (2) . . . . . . . . . . . . 14
4.1.27 Attribute Groups . . . . . . . . . . . . . . . . . . . . . 14
4.1.28 Containment . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.29 Single Inheritance . . . . . . . . . . . . . . . . . . . . 15
4.1.30 Reusable vs. Final Attribute Groups . . . . . . . . . . . 15
4.1.31 Events . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.32 Creation/Deletion . . . . . . . . . . . . . . . . . . . . 16
4.1.33 Range and Size Constraints . . . . . . . . . . . . . . . . 16
4.1.34 Uniqueness . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.35 Extension Rules . . . . . . . . . . . . . . . . . . . . . 17
4.1.36 Deprecate Use of IMPLIED Keyword . . . . . . . . . . . . . 17
4.1.37 No Redundancy . . . . . . . . . . . . . . . . . . . . . . 17
4.1.38 Compliance and Conformance . . . . . . . . . . . . . . . . 17
4.1.39 Allow Refinement of All Definitions in Conformance
Statements . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.40 Categories . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.41 Core Language Keywords vs. Defined Identifiers . . . . . . 19
4.1.42 Instance Naming . . . . . . . . . . . . . . . . . . . . . 19
4.1.43 Length of Identifiers . . . . . . . . . . . . . . . . . . 19
4.1.44 Assign OIDs in the Protocol Mappings . . . . . . . . . . . 20
4.2 Nice-to-Have Objectives . . . . . . . . . . . . . . . . . 20
4.2.1 Methods . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.2 Unions . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.3 Float Data Types . . . . . . . . . . . . . . . . . . . . . 21
4.2.4 Comments . . . . . . . . . . . . . . . . . . . . . . . . . 22
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. Introduction
This document describes the objectives for a new data definition
language that can be mapped into SNMP [1], [2] and COPS-PR [3]
protocol operations. It may also be translated into SMIv2 [4], [5],
[6] MIBs and SPPI [7] PIBs. Concepts such as attributes, attribute
groups, methods, conventions for organization into reusable data
structures, and mechanisms for representing relationships are
discussed.
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, PIBs, or LDAP schemas.
The result is that management interfaces for network protocols,
services, and applications such as Differentiated Services may be
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 data
definition language that will eliminate the need for a separate SMIv2
and SPPI language. That is, the new language should address the
needs for the current SMIv2 and SPPI languages so that over time we
can all use the new language instead.
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 formally define table existence relationships, the expression of
instance creation/deletion capabilities, and the ability to define
attribute groups using inheritance. These additional features are
discussed in subsequent sections.
It has been recognized that the two main goals of (a) merging
SMIv2/SPPI and (b) enhancing the state of art in network management
data modeling can lead to conflicts. In such cases, the SMIng
working group's consensus is to focus on enhancing the state of art
in network management data modeling.
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 definition 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 objectives 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 a meanwhile expired Internet Draft, but has
submitted their specification as one proposal to consider in the
development of the SMIng language.
The SMIng Working Group has accepted their submission for
consideration, and to use their proposal to better understand the
objectives and possible obstacles to be overcome. Where useful, the
NMRG proposal has been referenced in the details below.
4. Specific Objectives for SMIng
The following sections define the objectives for the definition of a
new data definition language. The objectives have been organized as
follows: accepted objectives (Section 4.1), nice-to-have objectives
(Section 4.2), and rejected objectives (Section 4.3). Each objective
has the following information:
o Type: a field that identifies the type of objective, using one of
the following values:
Elliott, et al. Informational [Page 4]
RFC 3216 SMIng Objectives December 2001
* basic: considered a basic objective for SMIng and is contained
in SMIv2 and/or SPPI.
* align: supported in different ways in SMIv2 and SPPI and they
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 that
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 objective
is not required by the SMIng working group, but justification why
it should be considered anyway. Notes may be the opinions of the
participants in the discussion on objectives and as such should
not be taken as consensus of the working group or the
recommendation of the objectives editing team.
4.1 Accepted Objectives
This section represents the list of objectives that have been
accepted by the SMIng working group as worthwhile and therefore
deserving of further consideration. Each of these objectives must be
evaluated by the working group to determine if the benefit incurs an
acceptable level of cost. An accepted objective may subsequently be
rejected if the cost/benefit analysis determines that the benefit
does not justify the cost or that the objective is in direct conflict
with one or more other accepted objectives that are deemed more
important.
Elliott, et al. Informational [Page 5]
RFC 3216 SMIng Objectives December 2001
4.1.1 The Set of Specification Documents
Type: new
From: NMRG
Description: SMIv2 is defined in three documents, based on an
obsolete ITU ASN.1 specification. SPPI is defined in one
document, based on SMIv2. The core of SMIng must be defined in
one document and must be independent of external specifications.
Motivation: Self-containment.
4.1.2 Textual Representation
Type: basic
From: SMI, SPPI, WG
Description: SMIng definitions must be represented in a textual
format.
Motivation: General IETF consensus.
4.1.3 Human Readability
Type: basic
From: WG
Description: The syntax must make it easy for humans to directly read
and write SMIng modules. It must be possible for SMIng module
authors to produce SMIng modules with text editing tools.
Motivation: The syntax must make it easy for humans to read and write
SMIng modules.
4.1.4 Rigorously Defined Syntax
Type: new
From: NMRG
Description: There must be a rigorously defined syntax for the SMIng
language.
Elliott, et al. Informational [Page 6]
RFC 3216 SMIng Objectives December 2001
Motivation: An unambiguous language promotes consistency across
vendors so that different parsers produce the same results. It
also provides authoritative rules to SMIng modules designers.
4.1.5 Accessibility
Type: align
From: SMI, SPPI
Description: Attribute definitions must indicate whether attributes
can be read, written, created, deleted, and whether they are
accessible for notifications, or are not accessible. Align PIB-
ACCESS and MAX-ACCESS, and PIB-MIN-ACCESS and MIN-ACCESS.
Motivation: Alignment of SMIv2 and SPPI.
4.1.6 Language Extensibility
Type: new
From: NMRG
Description: The language must have characteristics, so that future
modules can contain information 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
Type: new
From: WG
Description: Allow an escaping mechanism to encode special
characters, e.g. double quotes and new-line characters, in text
such as DESCRIPTIONs or REFERENCEs.
Motivation: ABNF can contain literal characters enclosed in double
quotes; to provide the ABNF grammar, there must be the ability to
escape special characters.
Elliott, et al. Informational [Page 7]
RFC 3216 SMIng Objectives December 2001
4.1.8 Naming
Type: basic
From: SMI, SPPI
Description: SMIng must provide mechanisms to uniquely identify
attributes, groups of attributes, and events. It is necessary to
specify how name collisions are handled.
Motivation: Already in SMIv2 and SPPI.
4.1.9 Namespace Control
Type: basic
From: SMI, SPPI
Description: There must be a hierarchical, centrally-controlled
namespace for standard named items, and a distributed namespace
must be supported to allow vendor-specific naming and to assure
unique module names across vendors and organizations.
Motivation: Need to unambiguously identify definitions of various
kinds. Some SMI implementations have problems with different
objects from multiple modules 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.
4.1.10 Modules
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.
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 Section
4.1.11.
4.1.11 Module Conformance
Type: basic
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?