SMIng Working Group A. Westerinen
INTERNET-DRAFT C. Elliott
Category: Informational Cisco Systems
Juergen Schoenwaelder
TU Braunschweig
Jamie Jason
Intel Corp.
Walter Weiss
Ellacoya
SMIng Requirements
<draft-ietf-sming-reqs-00.txt>
Friday, February 23, 2001, 11:32 AM
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
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Westerinen, et al. Expires: Feb 2001 + 6 months [Page 1]
Internet Draft SMIng Requirements February 2001
Abstract
This document describes the requirements of a data modeling
language suitable for the modeling of network management
constructs, and which can be translated into the various other
standardized representations that we have today - at a minimum,
at a minimum SMIv2 MIBs and SPPI PIBs.
This document will describe requirements for the construction of
a modeling language and the representation of basic modeling
constructs. These requirements are generally described in the
areas of reusability, extensibility, associability, naming,
expressiveness of data definitions through constraints, and
inheritance. The purpose of this document is to ensure that
subsequent documents that describe the conventions for the
language are complete and consistent with the requirements stated
herein.
Table of Contents
1. Introduction.................................................3
2. Motivation...................................................3
3. Specific Requirements for SMIng..............................4
3.1. Object Oriented Base....................................4
3.2. Naming..................................................5
3.2.1. Name collisions.......................................5
3.2.2. Class keys............................................6
3.3. Textual Representation..................................7
3.4. Data Types and Usage Semantics..........................7
3.5. Class Composition.......................................8
3.6. Combinations of Classes................................10
3.7. Grouping of Data Definitions to a Domain...............10
3.8. Semantic Constraints...................................10
3.9. Associations...........................................11
3.10. Methods...............................................12
3.11. Events................................................13
3.12. Versioning............................................13
3.13. Mapping Requirements..................................13
4. Conformance and Capability Reporting........................14
5. Glossary of Terms...........................................14
6. Acknowledgements............................................15
7. Security Considerations.....................................15
8. References..................................................15
9. Authors' Addresses..........................................16
10. Full Copyright Statement...................................17
Westerinen, et al. Expires: Feb 2001 + 6 months [Page 2]
Internet Draft SMIng Requirements February 2001
1. Introduction
This document describes the requirements for the definition of a
new object-oriented, data modeling language that is mappable to
SMIv2 [RFC2578] MIBs and [SPPI] PIBs. Concepts such as classes,
attributes, methods, conventions for organization into reusable
data structures, and mechanisms for representing relationships
are discussed.
Conventions used in this document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
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 [RFC1907], [PIB]s, or LDAP [RFC2252] schemas. The
result is that network applications and services such as DHCP or
Differentiated Services may be represented in many different
inconsistent fashions.
SMIng is proposed as 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.
Therefore, SMIng language constructs SHOULD be mappable to MIBs
and PIBs, but also be protocol independent and allow mappings to
other definitional languages (such as LDAP schemas).
The word, SHOULD, is used in the paragraph above since another
motivation for SMIng is to permit a more expressive and complete
representation of the modeled information. This implies that all
information expressed in SMIng may not be directly mappable to a
MIB or PIB construct, but may have to be conveyed in
documentation or via other mechanisms. Examples of additional
expressiveness and completeness are the ability to define
relationships between objects, the expression of constraints on
objects and properties, and the ability to define methods. This
issue is more fully discussed in Section 3.11, below.
Westerinen, et al. Expires: Feb 2001 + 6 months [Page 3]
Internet Draft SMIng Requirements February 2001
3. Specific Requirements for SMIng
3.1. Object Oriented Base
Object design provides support for the following features. These
MUST be supported by SMIng:
* Abstraction and classification - To reduce the complexity
of a problem domain, it is useful to first identify the high
level and fundamental concepts that apply in the domain.
These concepts are then grouped and classified into types
(i.e., "classes") by identifying common characteristics and
features (properties), relationships (associations) and
behavior (interfaces or methods).
* Object inheritance - Based on high level and fundamental
types/classes, additional detail can be provided. A subclass
"inherits" all the information (properties, methods and
associations) defined for its higher-level objects.
Inheritance allows a model to avoid redundant data definitions
among peer constructs, and define appropriate levels of
abstraction and complexity. Single inheritance is recommended
for SMIng, to optimize the model and its processing
requirements.
* Distinction between abstract and concrete - An abstract
class is one that has no instances (typically because it is
too generally defined). On the other hand, a concrete class
has instances. In order to fully support abstraction and then
specialization via inheritance, SMIng MUST support the ability
to distinguish abstract from concrete classes.
* Ability to depict dependency, aggregation, containment and
other relationships between objects. Relationships and
associations are discussed more extensively in Section 3.9
below.
* Standard, inheritable methods/interfaces - Although the
word "method" is used for consistency with previous
discussions, "interface" is a better term here. SMIng SHOULD
NOT define method implementation, but MUST support the
definition of standard method signatures (return value, method
name and input/output parameters). It is NOT desirable to
model read/write interfaces, since these are addressed by the
protocols and languages into which SMIng is mapped. But, it
is required that SMIng 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.
Westerinen, et al. Expires: Feb 2001 + 6 months [Page 4]
Internet Draft SMIng Requirements February 2001
Without a capability to define method signatures, we have the
potential to confuse return values and interface parameters with
class attributes. This obscures the semantics of a class.
3.2. Naming
A modeling language needs conventions for uniquely identifying
classes (constructs), attributes (properties or data), events and
method signatures. Class naming and the ability to uniquely
identify defined attributes, events and methods are important
parts of any modeling language. Naming conventions must be
developed that can be used equally effectively for reuse as well
as to extend existing classes. Mechanisms that are complimentary
to object-oriented naming conventions while not requiring the use
of a central naming authority are required.
Note that only class/attribute/method/event DEFINITIONS (as
opposed to individual instances) are addressed here. Instance
naming is left to the individual, protocol-specific mappings
(i.e., one mechanism might be to use OIDs to identify class
instances). However, the language should support the
identification of attributes which must be unique and/or which
can be used as a key or key structure. (Note that it is not
required that each attribute in a compound key be unique, just
that the compound key must be unique.) The key(s) of a class are
basically one or more attributes whose value(s) uniquely identify
an instance.
It is assumed that keys exist and can be created in a number of
ways, and that uniqueness within a context is required. But,
SMIng should not force a particular keying mechanism or even
force the definition of a key. If desired, however, a key
structure should be able to be expressed. This is discussed more
fully in Section 3.2.2 below.
3.2.1. Name collisions
It is obvious that as the number of defined classes increases,
the likelihood of a collision in naming will also increase. When
defining naming conventions, SMIng MUST take this into account
and provide a mechanism to reduce the likelihood of class name
collisions. For example, the mechanism employed in C++ is the
introduction of namespaces to add a level of name scoping.
Another example of name collision, although not as obvious,
results when inheritance is utilized. Take the following
example:
class foo
{
string description;
}
Westerinen, et al. Expires: Feb 2001 + 6 months [Page 5]
Internet Draft SMIng Requirements February 2001
class bar derives from foo
{
string description;
}
When dealing with an object of type bar, a reference to the
attribute named description MUST refer to the attribute defined
in the leaf class (i.e., in bar). Essentially, any
attribute/method defined in a derived class hides an
attribute/method with the same name that is defined in any of its
base classes. While it is not required of a compiler, it SHOULD
print a warning message when a derived class hides a base class'
attribute, method or event.
3.2.2. Class keys
Experience has shown that different technologies (and even
different implementations of the same technology) use different
mechanisms for defining instance naming mechanisms, binding
attribute groups to keys, and creating indexing schemes.
However, the need to define a key structure and identify an
instance is universal. SMIng MUST support the ability to identify
an attribute or group of attributes as a key for class instances.
For example, a keyword (such as "key") MAY be defined to indicate
that a class' attribute is to be used as part of the instance
key. (Now, that attribute may also have to be "unique" across
all instances in a certain context, but this is a different
concept than "key".)
SMIng MUST NOT dictate the format of these keys. That is, keys
can be created in a number of ways. It will however, be
important to understand how a particular implementation defines
its keys and thereby names instances. Without this information,
mapping between implementations will be difficult or impossible.
Defining attributes as instance keys for a simple object, i.e. an
object that neither contains nor derives from other objects, is
straightforward. However, instance keying becomes more
complicated when inheritance is introduced.
Inheritance can be thought of as a kind of class composition,
where the attributes of the base class(es) are contained in the
derived class. Therefore, the rules SHOULD apply: attributes in
a base class that are marked as keying material MUST be used as
keying material for the derived class, but there MUST be the
ability for a derived class to indicate on an attribute-by-
attribute case that the keying material from a base class is NOT
to be used as keying material for the derived class. However,
overriding or hiding of a attribute marked in the base class as a
key SHOULD NOT be permitted.
Westerinen, et al. Expires: Feb 2001 + 6 months [Page 6]
Internet Draft SMIng Requirements February 2001
Therefore, a class' keying material is comprised of: (1) any
attributes marked as keying material, and (2) any attributes in
any of the class' base classes marked as keying material, but not
marked as omitted from keying.
3.3. Textual Representation
It is necessary to have a textual representation suitable for
representing a data model, completely and unambiguously, which is
readily parseable and verifiable by a computer program.
Sufficient constructs must exist to convey critical model
information, such as usage and semantics constraints (see
Sections 3.4 and 3.8, respectively). "Critical model
information" should never be conveyed solely in a description,
since this is not parseable or verifiable. The textual
representation should provide sufficient detail for algorithmic
mappings of the data model to as large a cross-section of
protocols/interfaces as possible. At a minimum, translation to
MIBs and PIBs must be supported. It is understood that this
translation is likely to be lossy.
3.4. Data Types and Usage Semantics
To facilitate reuse, all data elements described using SMIng MUST
be clearly defined in terms of characteristics, scope and
relationships to other elements. This can be achieved through
language constructs, data types and value bounding which should
be explicitly defined for attributes, classes, events, methods,
and associations between constructs.
Mechanisms MUST be provided for describing the fundamental data
types of attributes (for example, integer, real, octet string,
etc.), as well as describing arrays of these basic data types.
All necessary data types for MIB/PIB support MUST be defined in
SMIng, as well as the set of base data types in common
programming languages. However, it is requested that SMIng not
restrict the data types to a fixed set. As the computing
environment evolves, new data types may be required and the
language must support their definition. Uint128s are an example.
It is understood that adding base data types without changing a
language is difficult to support in implementations. If so,
versioning (Section xxx) is critical.
Included in the list of basic data types is the ability to point
to, or reference an instance of a class. These
pointers/references are indicators of identity and are assumed to
hold information appropriate to the language and protocol to
which SMIng is mapped.
Higher order semantics can be defined for, and added to the basic
data types. An example is the ability to refine the definition
of an integer attribute to indicate that it behaves as a counter
Westerinen, et al. Expires: Feb 2001 + 6 months [Page 7]
Internet Draft SMIng Requirements February 2001
or gauge. Support for defining and using these higher order
semantics MUST be provided in SMIng. In addition, the ability to
define a sequence of attributes (similar to a C language struct)
MUST be provided. Whether these capabilities are met via native
language constructs, or the use of existing language features
(for example, the ability to use another class' definition within
a class, Section 3.5) will be determined by the work group. It
is not necessary that these requirements be met by native
constructs of the language.
In addition to the ability to define basic data types, usage
semantics for classes and attributes are needed, describing:
* Constraints for attributes. E.g., Attribute X is an integer
that can have values in the range 10-100 and 234-235.
* Support for enumerations of attributes. Two different
enumeration types exist: One which works like a C enum where
you define possible values in place, and a second one where
possible values can be defined in a distributed name space.
The first one provides you no or only centrally controlled
extensibility (e.g. IANA), while the second one gives you more
flexible, but requires coordinated extensibility.
* Indication of read-only, read-write and write-only
attributes. While the majority of attributes can be retrieved
and altered, for some attributes, such as counters or hard
wired MAC addresses, it is only possible to retrieve the value
but not to alter it. There may even be instances where an
attribute value can be altered, but not retrieved.
* Definition of required or optional.
* Definition of requirements to be unique within a context.
* Definition of abstract (general) classes versus concrete
(instantiable) ones. (This was also discussed in Section 3.1,
above.)
* Constraints on associations and pointers -- ie, cardinality.
3.5. Class Composition
The modeling language must allow classes to be composed from more
basic classes - i.e., to contain the attribute (property) set of
other classes. This will maximize reuse and allow data to be
completely described with minimum redundancy. For example, Class
XYZ can contain as attributes, Class ABC and Class DEF. The
result would be that Class XYZ's attribute set would be a
superset of Classes ABC and DEF.
Westerinen, et al. Expires: Feb 2001 + 6 months [Page 8]
Internet Draft SMIng Requirements February 2001
Note that this is sometimes referred to as "containment," but use
of that word is avoided here. It is easily confused with a
"containment" association that describes the ownership, scoping
and naming of instances within the context of another object.
As an example of class composition, consider the classes,
InetSubnet and InetPortNumberRange, that define and constrain
Internet addressing and port ranges. One could create a new
Filter Class that looks something like this:
class InetFilter : Filter {
attribute InetSubnet srcSubNet { ... };
attribute InetSubnet dstSubNet { ... };
attribute InetPortRange srcPortRange { ... };
attribute InetPortRange dstPortRange { ... };
attribute InetProtocolNumber protocol { ... };
...
};
Where InetSubnet and InetPortNumberRange are defined as follows:
class InetSubnet {
attribute InetAddressType type { ... };
attribute InetAddress address { ... };
attribute InetAddressPrefixLengh prefix { ... };
...
};
class InetPortNumberRange {
attribute InetPortNumber start { ... };
attribute InetPortNumber end { ... };
...
};
In InetFilter, the contained InetSubnet and InetPortNumberRange
classes are not to be merged into one attribute, but remain
individually identifiable "contained" classes. The contained
classes define source/destination information for the filter.
It is strongly recommended that this mechanism only be used when
including one class' attribute list in another class' definition.
Inclusion of a class' events, methods, keys, etc. is not
recommended. In fact, if the "contained" class could be directly
instantiated and may exist independently of the containing class,
it is recommended that this approach NOT be used. Instead, the
two classes should be related via an association.
It is important that all data models have standard mappings of
this strictly definitional model into their data model-specific
forms.
Westerinen, et al. Expires: Feb 2001 + 6 months [Page 9]
Internet Draft SMIng Requirements February 2001
3.6. Combinations of Classes
When hundreds of classes may be defined in a data model, there is
a need to create "standard" combinations of classes and
associations, describing common scenarios. It MUST be possible
to describe and easily include these combinations of classes and
associations using formalisms in SMIng. These standard
combinations would be useful in reducing the arbitrariness of
which classes to use (if a large data model exists) to solve a
particular modeling problem.
There MUST be a definitional grouping of modeling information
similar to a MIB Module, and the ability to import or include a
grouping. In the future, there may also be an operational aspect
to the grouping. On the operational side, it is observed that
certain combinations of classes and associations are always
instantiated, retrieved and manipulated together. For
efficiency, these could be identified as "operationally grouped"
and appropriate for bulk operations. It is acknowledged that all
protocols and mappings do not support this capability.
3.7. Grouping of Data Definitions to a Domain
It is sometimes necessary to group data definitions into subject
categories or contexts. Concrete instances may exist only in the
scope of a given subject category or context. It is possible that
similar instances, even with the same instance name/keys, coexist
in different contexts. A good example is an object that applies
to many functional areas. Implementations that focus on a
concrete functional area instantiate these objects independent
from each other. Another example is an object instance that
exists in several contexts that vary by time (i.e., snapshots) or
purpose (such as a backup configuration).
The SMIng language MUST provide support for protocol mechanisms
that distinguish between contexts or subject categories.
3.8. Semantic Constraints
The ability to specify semantic constraints is needed.
Constraints are the specification of the characteristics, value
or existence of a model construct relative to another construct.
The subsequent list of constraints, while not necessarily
complete, is a minimal set that MUST be supported by SMIng.
When a specific mapping of SMIng to another form is defined and
the target data modeling language has a less robust mechanism for
expressing constraints, additional documentation should accompany
the data model to minimize confusion.
Support for the following semantic constraints is needed:
Westerinen, et al. Expires: Feb 2001 + 6 months [Page 10]
Internet Draft SMIng Requirements February 2001
* Constraints for classes. E.g., Class A should be created
when Class B's attribute x is "OK".
* Constraints for class/attribute associations. For example,
one may only want to allow an instance of class A to be
associated with an instance of class B, if A is not already
associated with class C.
* Constraints for attribute transactions. E.g., attribute A
and attribute B must be modified together.
* Constraints on attribute values, where one or more
attributes may affect the value or range of values for another
attribute. One such relationship exists in IPSEC, where the
type of security algorithm determines the range of possible
values for other attributes such as the corresponding key
size. The most extreme form of multi-attribute relationships
is a set of attributes that are dependent on each other for
consistency. For example, a class may have two attributes, one
expressing a date and the other expressing a day of the week.
When the day of the week is changed, the date should change
simultaneously and visa versa, to prevent inconsistencies.
SMIng MUST express this level of relationship between
attribute values.
3.9. Associations
Associations describe relationships between instances of classes.
They define how an object of one class relates to other objects.
Various types of associations exist - general relationships such
as dependencies, aggregations (whole-part) and containment for
scoping and naming.
There are a few things to note about associations: 1)
relationships are primarily between only two class instances
(i.e., they are binary); 2) the same relationship may be repeated
for a particular instance, associating that instance with others;
and 3) relationships can be implemented as classes or as inline
references within a class definition. Regarding the latter, both
class definitions and inline references SHOULD be supported by
SMIng. (A class implementation is required when an association
carries data or methods.) Regarding the first item, it is
recommended that ONLY binary associations be supported by SMIng.
The cardinality of a reference in an association MUST be
expressable in SMIng. If you have an association between classes
A and B, the cardinality of A indicates how many instances of A
may be associated with a single instance of B. Cardinalities can
take the following forms:
* Single integer value (for example, 1)
Westerinen, et al. Expires: Feb 2001 + 6 months [Page 11]
Internet Draft SMIng Requirements February 2001
* A range of integer values (for example, 0..1 or 2..4)
* A set of single integers or integer ranges (for example, 1,
3, 6..8)
* An asterisk alone or in a range (representing an unlimited
upper bound)
These types of cardinalities MUST be expressable in SMIng.
An example of an association is the representation of a device's
software. A device may have various types of software associated
with it - configuration, operational and instrumentation software
are just a few examples. So, software can be "associated" with
one or more devices, and devices can have one or more pieces of
software. The use of the software for the device can be
described as a property of the association.
It should be noted that separate association classes force data
classes to be maximally reusable, as the data class then makes no
assumptions about how it can be related to other classes.
3.10. Methods
In an object-oriented implementation, a class' methods describe
the actions or behaviors that are appropriate for, and can be
invoked against, an instance. Method signatures allow the
specification of return codes and input/output parameters,
further influencing the specific action or behavior. The goal of
defining a method signature is to describe and invoke well-
defined behaviors - describing the intent of the behavior, return
code/status and parameters.
Methods must operate under the same modeling restrictions as
those described in Section 3.4 (usage semantics) and 3.8
(semantic constraints). Mechanisms must be provided in the model
to fully specify the operating constraints of both the method and
the attributes passed to and from it.
Specifically, method definition should address:
* Constraints for parameters passed through a method. E.g.,
Attribute X is an integer that can have values in the range
10-100 and 234-235.
* Indication of input-only, input-output, or output-only
parameters.
* Return value data type
* If the modeling language supports the ability to have a
class or class reference as a parameter, the constraints of
Westerinen, et al. Expires: Feb 2001 + 6 months [Page 12]
Internet Draft SMIng Requirements February 2001
these class parameters should be fully specified if different
from the general definition of the class. E.g., Method AÆ of
Class A allows an instance of Class B to be removed or copied.
* Constraints on the interdependencies between parameters of a
method. One possible scenario is when a class (passed as a
reference) is modified if another parameter has a particular
value.
* If it is possible for one method to invoke or use another
method, this must be documented. This is particularly
important when the model requires that a particular set of
external methods be used to obtain specific functionality.
3.11. Events
Events indicate occurrences which should be reported or which
will result in a change of state. At a minimum, the events
appropriate for a class must be defined (i.e., named) and any
data to be reported with the event identified.
3.12. Versioning
It is necessary to evolve data definitions over time to
accommodate technology changes or to add support for new
features. In a highly distributed environment, it is important to
be able to evolve data definitions without causing
interoperability problems with deployed systems that implement an
earlier version of a given data model.
Authors of data definitions may not always be aware of the
interoperability implications when they update published data
definitions. SMIng MUST therefore provide clear rules which
define the set of changes that do not cause interoperability
problems "over the wire" when extending an SMIng module. These
rules must be described precisely enough so that it is possible
to implement automatic tools which verify that updates comply to
the rules.
A clear versioning scheme MUST be in place to support the cases
where interoperability is impossible (such as the definition of
new basic data types).
3.13. Mapping Requirements
As SMIng will be mapped to a variety of representations, it is
recognized that not all of these representations will be capable
of supporting the model's constructs completely. Mapping
information and divergences should be expressable in the
language.
Westerinen, et al. Expires: Feb 2001 + 6 months [Page 13]
Internet Draft SMIng Requirements February 2001
All constructs in the language must have a documented mapping to
SMIv2 and SPPI, and/or the SNMP and COPS-PR protocols, at a
minimum. In cases where mappings are lossy, the missing
information from the SMIng model should be retained in the mapped
representation, via comments, descriptions or similar textual
mechanisms.
4. Conformance and Capability Reporting
<TBD>
5. Glossary of Terms
Association: A relationship between the instances of
classes. Associations are typically binary, and convey the
semantics of the class' connection.
Aggregation: A whole-part relationship.
Attribute: An atomic or composite data type that is fully
described, typed, uniquely named, and optionally bounded via
constraints. It represents the common characteristics or
features of an object.
Class: A set of one or more attributes and methods, that can
participate in associations and that can inherit properties
from parent classes to optimize data definitions. It
represents a grouping or typing of "like" objects.
Composition: The ability to define a class using the names
of other classes, as though these "contained" classes were
data types. The result is to include one class' property
set within another class' definition. (See also
"containment.")
Constraint: A mechanism for bounding an attribute or class
value to allowed values/ranges/targets/bitmaps etc. There
are both data level and semantic constraints.
Containment (1): An association that describes the ownership,
scoping and naming of instances within the context of another
object.
Containment (2): The ability to contain a class' property
set within another class' definition. This is referred to
as "class composition" in this document.
Definition Name: Unique name used to identify an attribute
or class definition.
Westerinen, et al. Expires: Feb 2001 + 6 months [Page 14]
Internet Draft SMIng Requirements February 2001
Event: Occurrences which should be reported or which will
result in a change of state.
Instance Name: Key: Index: One or more attributes of a class
whose value(s) uniquely identify an instance.
Interface: (See "method signature.")
Method: The specification of a behavior or operation,
having a specific signature, included in a class definition.
Method Signature: The definition of a method's name, return
value, and input/output parameter list. This is also known
as an "interface."
Object-Oriented Modeling: Representation of a domain of
discourse by grouping or typing its objects (into
"classes"). This is accomplished by identifying common
characteristics and features of the objects (properties),
relationships (associations) and ability to affect state
changes (methods).
6. Acknowledgements
Special thanks to Dave Durham, whose work on the original NIM
(Network Information Model) draft was used in generating this
document.
7. Security Considerations
This document defines a language with which to describe
management information. The language itself has no security
impact on the Internet.
8. References
[PIB] Fine, M., McCloghrie, K., Seligson, J., Chan, K., Hahn, S.,
Sahita, R., Smith, A., Reichmeyer, F., "Framework Policy
Information Base", draft-ietf-rap-frameworkpib-03.txt.
[SPPI] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn,
S., Sahita, R., Smith, A., Reichmeyer, F., "Structure of Policy
Provisioning Information (SPPI)", draft-ietf-rap-sppi-04.txt.
[RFC1907] Case, J., McCloghrie, K., Rose, M., Waldbusser, S.,
"Management Information Base for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1907, January 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
Westerinen, et al. Expires: Feb 2001 + 6 months [Page 15]
Internet Draft SMIng Requirements February 2001
[RFC2252] Wahl, M., and A. Coulbeck, T. Howes, S. Kille,
"Lightweight Directory Access Protocol (v3): Attribute Syntax
Definitions", December 1997.
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
J., Rose, M., Waldbusser, S., "Structure of Management
Information Version 2 (SMIv2)", April 1999.
[RFC2925] White, K., "Definitions of Managed Objects for Remote
Ping, Traceroute, and Lookup Operations", September 2000.
9. Authors' Addresses
Andrea Westerinen
Cisco Systems
725 Alder Drive
Milpitas, CA 95035
E-mail: andreaw@cisco.com
Chris Elliott
Cisco Systems
7025 Kit Creek Road
Research Triangle Park, NC 27709
E-mail: chelliot@cisco.com
Juergen Schoenwaelder
TU Braunschweig
Bueltenweg 74/75
38106 Braunschweig
Germany
E-Mail: schoenw@ibr.cs.tu-bs.de
Jamie Jason
Intel Corporation
MS JF3-206
2111 NE 25th Ave.
Hillsboro, OR 97124
E-Mail: jamie.jason@intel.com
Walter Weiss
Ellacoya Networks
7 Henry Clay Dr.
Merrimack, NH. 03054
E-mail: wweiss@ellacoya.com
Westerinen, et al. Expires: Feb 2001 + 6 months [Page 16]
Internet Draft SMIng Requirements February 2001
10. Full Copyright Statement
Copyright (C) The Internet Society (2000). 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.
Westerinen, et al. Expires: Feb 2001 + 6 months [Page 17]
