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 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 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]