Network Working Group A. Westerinen Internet-Draft C. Elliott Expires: November 12, 2001 Cisco Systems J. Schoenwaelder F. Strauss TU Braunschweig J. Jason Intel Corporation W. Weiss Ellacoya Networks May 14, 2001 SMIng Requirements draft-ietf-sming-reqs-01.txt 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 November 12, 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, 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 Westerinen, et. al. Expires November 12, 2001 [Page 1] Internet-Draft SMIng Requirements May 2001 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 . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Specific Requirements for SMIng . . . . . . . . . . . . . . 5 3.1 Textual Representation . . . . . . . . . . . . . . . . . . . 6 3.2 Human Readability . . . . . . . . . . . . . . . . . . . . . 6 3.3 Machine Readability . . . . . . . . . . . . . . . . . . . . 7 3.4 Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.5 Namespace Control . . . . . . . . . . . . . . . . . . . . . 8 3.6 Modules . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.7 Protocol Independence . . . . . . . . . . . . . . . . . . . 8 3.8 Protocol Mapping . . . . . . . . . . . . . . . . . . . . . . 8 3.9 Translation to Other Data Definition Languages . . . . . . . 8 3.10 Incomplete Translations . . . . . . . . . . . . . . . . . . 9 3.11 Instance Naming . . . . . . . . . . . . . . . . . . . . . . 9 3.12 Base Data Types . . . . . . . . . . . . . . . . . . . . . . 9 3.13 Extended Data Types . . . . . . . . . . . . . . . . . . . . 9 3.14 Instance Pointers . . . . . . . . . . . . . . . . . . . . . 9 3.15 Row Pointers . . . . . . . . . . . . . . . . . . . . . . . . 10 3.16 Base Type Set . . . . . . . . . . . . . . . . . . . . . . . 10 3.17 Accessibility . . . . . . . . . . . . . . . . . . . . . . . 11 3.18 Derived Types . . . . . . . . . . . . . . . . . . . . . . . 12 3.19 Enumerations . . . . . . . . . . . . . . . . . . . . . . . . 12 3.20 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.21 Creation/Deletion . . . . . . . . . . . . . . . . . . . . . 12 3.22 Range and Size Constraints . . . . . . . . . . . . . . . . . 13 3.23 Constraints on Pointers . . . . . . . . . . . . . . . . . . 13 3.24 Uniqueness . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.25 Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.26 Table Existence Relationships . . . . . . . . . . . . . . . 14 3.27 Extension Rules . . . . . . . . . . . . . . . . . . . . . . 14 3.28 Categories . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.29 Agent Capabilities . . . . . . . . . . . . . . . . . . . . . 15 3.30 Remove IMPLIED Keyword . . . . . . . . . . . . . . . . . . . 15 3.31 No Redundancy . . . . . . . . . . . . . . . . . . . . . . . 15 3.32 Discriminated Unions . . . . . . . . . . . . . . . . . . . . 15 3.33 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.34 Single Inheritance . . . . . . . . . . . . . . . . . . . . . 16 Westerinen, et. al. Expires November 12, 2001 [Page 2] Internet-Draft SMIng Requirements May 2001 3.35 Abstract vs. Concrete Classes . . . . . . . . . . . . . . . 17 3.36 Relationships . . . . . . . . . . . . . . . . . . . . . . . 18 3.37 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.38 Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.39 Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.40 Composition . . . . . . . . . . . . . . . . . . . . . . . . 20 3.41 Existence Constraints . . . . . . . . . . . . . . . . . . . 20 3.42 Ordering Constraints . . . . . . . . . . . . . . . . . . . . 21 3.43 Attribute Transaction Constraints . . . . . . . . . . . . . 21 3.44 Attribute Value Constraints . . . . . . . . . . . . . . . . 21 3.45 Associations . . . . . . . . . . . . . . . . . . . . . . . . 22 3.46 Association Cardinalities . . . . . . . . . . . . . . . . . 22 3.47 Method Constraints . . . . . . . . . . . . . . . . . . . . . 22 3.48 Table Relationships . . . . . . . . . . . . . . . . . . . . 23 3.49 Float Data Types . . . . . . . . . . . . . . . . . . . . . . 23 3.50 Compliance and Conformance . . . . . . . . . . . . . . . . . 23 3.51 Categories of Modules . . . . . . . . . . . . . . . . . . . 23 3.52 Language Extensibility . . . . . . . . . . . . . . . . . . . 24 3.53 Length of Identifiers . . . . . . . . . . . . . . . . . . . 24 3.54 Why Are So Many SMIv1/v2 So Error Tolerant? . . . . . . . . 24 3.55 Core Language Keywords vs. Defined Identifiers . . . . . . . 25 3.56 i18n . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.57 Special Characters in Texts . . . . . . . . . . . . . . . . 26 3.58 Mapping Modules to Files . . . . . . . . . . . . . . . . . . 26 3.59 Comments . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.60 Simple Grammar . . . . . . . . . . . . . . . . . . . . . . . 27 3.61 Place of Module Information . . . . . . . . . . . . . . . . 27 3.62 Fully Qualified Identifiers . . . . . . . . . . . . . . . . 28 3.63 Readable Revision Date Representation . . . . . . . . . . . 28 3.64 Make Status Information Optional . . . . . . . . . . . . . . 28 3.65 Units and Default Values of Defined Types . . . . . . . . . 29 3.66 Arbitrary Unambiguous Identities . . . . . . . . . . . . . . 30 3.67 Remove OIDs from the Core Language . . . . . . . . . . . . . 30 3.68 Module Namespace . . . . . . . . . . . . . . . . . . . . . . 30 3.69 Problem: Where to Put Constraints Required by the Protocol? 31 3.70 Problem: Phrasing Descriptions . . . . . . . . . . . . . . . 31 3.71 Problem: Mapping Protocol Specific Attributes . . . . . . . 32 3.72 Hyphens in Identifiers . . . . . . . . . . . . . . . . . . . 32 3.73 The Set of Spec Documents . . . . . . . . . . . . . . . . . 33 3.74 Allow Refinement of All Definitions in Conformance Statements 33 3.75 Referencing a Group of Instances of a Class . . . . . . . . 33 4. Conformance and Capability Reporting . . . . . . . . . . . . 34 5. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . 34 6. Security Considerations . . . . . . . . . . . . . . . . . . 35 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 References . . . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 36 Full Copyright Statement . . . . . . . . . . . . . . . . . . 38 Westerinen, et. al. Expires November 12, 2001 [Page 3] Internet-Draft SMIng Requirements May 2001 1. Introduction This document describes the requirements for the definition of a new object-oriented, data modeling language that is mappable to SMIv2 [2], [3], [4] MIBs and [8] 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 [1]. 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 [5], PIBs [9], or LDAP [6] 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.37 and others, below. 3. Specific Requirements for SMIng The following sections define the requirements for the definition of an object-oriented, data-modeling language. Frank Strauss also maintains a web page[10] that contains the same information, albeit Westerinen, et. al. Expires November 12, 2001 [Page 4] Internet-Draft SMIng Requirements May 2001 in a slightly different format. Each requirement has the following information: o Status: a field with one or more 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 proven 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 which is not required in SMIng, but could be added if working group consensus to do so is reached. o From: a field which defines where the requirement was derived from and has one or more of the following values: * WG: has been proposed during working group discussions. * SMI: exists already in SMIv2. * SPPI: exists already in SPPI. * SMIng: exists in current SMIng specification proposal, but not in SMIv2 or SPPI. * Charter: exists in working group charter. * Individual: proposed by working group participant. o Description: a quick description of the requirment. o Motivation: rationale for the requirement o Discussion: discussion generated by the requirement 3.1 Textual Representation Status: basic From: SMI, SPPI, WG Description: SMIng definitions must be represented in a textual format. Motivation: General IETF consensus. 3.2 Human Readability Status: basic From: WG Description: The syntax should make it possible for humans to read and write SMIng modules. It should be possible to read and write SMIng modules with text processing tools. Motivation: The syntax should make it easy for humans to read and write SMIng modules. Discussion: * Jamie: One thing I have noticed reading the IPsec PIB and MIB documents is that the semantics of the model being presented Westerinen, et. al. Expires November 12, 2001 [Page 5] Internet-Draft SMIng Requirements May 2001 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. 3.3 Machine Readability Status: 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 encourages the usage of compiler toolkits to construct solid parsers. Avoiding unnecessary forward references simplifies parser internal data management and allows for early error detection. 3.4 Naming Status: basic From: SMI, SPPI Description: SMIng should provide mechanisms to uniquely identify attributes, groups of attributes, and events. It is necessary to specify how name collisions are handled. 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. Westerinen, et. al. Expires November 12, 2001 [Page 6] Internet-Draft SMIng Requirements May 2001 3.5 Namespace Control Status: basic From: SMI, SPPI Description: There should be a centrally controlled namespace for standard named items. A distributed namespace should be supported to allow vendor-specific naming. Motivation: 3.6 Modules Status: basic From: SMI, SPPI Description: SMIng must provide a mechanism for uniquely identifying a module, and specifying the status of a module, the contact person for a module, the revision information for a module, and the purpose of a module. Motivation: SMIng must provide mechanisms to group definitions into modules and it must provide rules to reference definitions from other modules SMIng must provide mechanisms to detail the minimum requirements implementors must meet to claim conformance to a standard based on the module. Modularity, namespace scoping, and independent advancement of documents. 3.7 Protocol Independence Status: basic From: Charter Description: SMIng must define protocol independent data definitions. Motivation: So they can be used with multiple protocols. 3.8 Protocol Mapping Status: basic From: Charter Description: SMIng MUST define mappings of protocol independent data definitions to the SNMP and COPS-PR protocols. Motivation: SMIng working group charter. 3.9 Translation to Other Data Definition Languages Status: basic From: Charter Description: SMIng language constructs SHOULD be mappable to MIBs and Westerinen, et. al. Expires November 12, 2001 [Page 7] Internet-Draft SMIng Requirements May 2001 PIBs and allow mappings to other definitional languages (such as LDAP schemas). Motivation: Backwards compatibility with existing tools. 3.10 Incomplete Translations Status: 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. 3.11 Instance Naming Status: 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. 3.12 Base Data Types Status: basic From: SMI, SPPI Description: SMIng must support the base data types Integer32, Unsigned32, Integer64, Unsigned64, Enumeration, Bits, OctetString. Motivation: Most are already common. Unisgned64 and Integer64 are in SPPI, must fix in SMI. 3.13 Extended Data Types Status: align From: SMI, SPPI Description: SMIng must allow a mechanism to allow types to be defined as new types which provide additional semantics. Counters, Gauges, Strings, etc. Motivation: SMI uses application types and textual conventions. SPPI uses derived types. 3.14 Instance Pointers Status: basic From: SPPI Description: SMIng must allow specifying pointers to instances. Westerinen, et. al. Expires November 12, 2001 [Page 8] Internet-Draft SMIng Requirements May 2001 Motivation: It is common practice in MIBs and PIBs to point to other instances. Discussion: * 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 are done with supporting pointers to class instances or whether we also need pointers to concrete attributes of class instances.) 3.15 Row Pointers Status: align From: SMI, SPPI Description: SMIng must allow specifying pointers to rows. Motivation: It is common practice in MIBs and PIBs to point to other rows (see RowPointer, PIB-REFERENCES). 3.16 Base Type Set Status: 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. Motivation: Interoperability. Westerinen, et. al. Expires November 12, 2001 [Page 9] Internet-Draft SMIng Requirements May 2001 3.17 Accessibility Status: 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: Interoperability. Discussion: * 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. Westerinen, et. al. Expires November 12, 2001 [Page 10] Internet-Draft SMIng Requirements May 2001 3.18 Derived Types Status: basic From: SMI, SPPI Description: SMIng must allow a mechanism to allow base types to be defined as new types which provide additional semantics. It may be desirable to also allow the derivation of new types from derived types. Motivation: Textual Conventions permit this in SMIv2. Derived types permit this in SPPI. 3.19 Enumerations Status: basic From: SMI, SPPI Description: SMIng should provide support for enumerations with a distributed and a centrally controlled namespace. Motivation: SMIv2 already has enumerated numbers and OIDs that can be used to identify things. Enumerated numbers are defined in a single place while OIDs can be defined independently in arbitrary places. 3.20 Events Status: 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. 3.21 Creation/Deletion Status: 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. Discussion: * 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". rfc2578.txt discusses using the MAX-ACCESS clause to indicate whether it makes protocol sense to create an instance of an Westerinen, et. al. Expires November 12, 2001 [Page 11] Internet-Draft SMIng Requirements May 2001 object. As I see it, both recognize the need to be able to create "things" in the protocol. RFC2579 has the RowStatus T-C 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. 3.22 Range and Size Constraints Status: 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. 3.23 Constraints on Pointers Status: 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. 3.24 Uniqueness Status: basic From: SPPI Description: SMIng should allow to specify uniqueness constraints on attributes. 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. 3.25 Tables Status: basic From: SMI, SPPI Description: SMIng should provide a mechanism for grouping attributes Westerinen, et. al. Expires November 12, 2001 [Page 12] Internet-Draft SMIng Requirements May 2001 as tables. Motivation: 3.26 Table Existence Relationships Status: basic From: SMI, SPPI Description: SMIng should support INDEX, AUGMENTS, and EXTENDS. Motivation: These three table existence relationships exists either in the SMIv2 or the SPPI. 3.27 Extension Rules Status: 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. 3.28 Categories Status: basic From: SPPI Description: SMIng must provide mechanisms 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. Discussion: * 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++ namespacese. 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. ;-) Westerinen, et. al. Expires November 12, 2001 [Page 13] Internet-Draft SMIng Requirements May 2001 3.29 Agent Capabilities Status: basic From: SMI Description: SMIng must provide mechanisms to describe implementation. Motivation: To permit manager to determine variations from the standard for an implementation. Discussion: * 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. 3.30 Remove IMPLIED Keyword Status: should From: SMI Description: SMIng SNMP mapping should remove the IMPLIED indexing schema. Motivation: It is impossible to extend tables which contain IMPLIED indexes without causing the extended table being in a different lexicographic order. Discussion: * 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. 3.31 No Redundancy Status: 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. 3.32 Discriminated Unions Status: should From: WG Description: SMIng should support a standard format for discriminated unions. Westerinen, et. al. Expires November 12, 2001 [Page 14] Internet-Draft SMIng Requirements May 2001 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-arounds in some DISMAN mid-level manager MIBs. 3.33 Classes Status: new From: SMIng Description: SMIng should provide a mechanism for reuse of non- divisible, extensible attribute groupings. 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 (InetAddressType, InetAddress). Discussion: * 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"? * 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. 3.34 Single Inheritance Status: new From: SMIng Description: SMIng should provide support for mechanisms to extend attribute groupings (inheritance). Motivation: Allows to extend grouping of attributes, like a generic DiffServ scheduler, with attributes for a specific scheduler, without cut&paste. Discussion: * 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 Westerinen, et. al. Expires November 12, 2001 [Page 15] Internet-Draft SMIng Requirements May 2001 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 inheritence could help in this situation. Cut&paste is not needed. Table relationships are the key. * Frank: Another motivation: Inheritence 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 methodolgy 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. 3.35 Abstract vs. Concrete Classes Status: new From: SMIng, WG Description: SMIng should differentiate between abstract and concrete grouping of attributes. Motivation: This informations gives people more information how classes can and should be used. It hinders them from misusing abstract classes. Discussion: * 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 derive from the abstract base class. Westerinen, et. al. Expires November 12, 2001 [Page 16] Internet-Draft SMIng Requirements May 2001 3.36 Relationships Status: new From: SMIng, WG Description: Ability to formally depict existence dependency, value dependency, aggregation, containment, and other relationships between attributes or grouping of attributes. Motivation: Helps humans to understand the conceptual model of a module. Helps implementors of MIB compilers to generate more `intelligent' code. 3.37 Methods Status: 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. Discussion: * 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 modelling 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) modelling 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 Westerinen, et. al. Expires November 12, 2001 [Page 17] Internet-Draft SMIng Requirements May 2001 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 modelling 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- 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. 3.38 Procedures Status: new From: WG Description: SMIng should support a mechanism to formally define procedures that are used by managers when interacting with an agent. Motivation: 3.39 Arrays Status: new From: WG Westerinen, et. al. Expires November 12, 2001 [Page 18] Internet-Draft SMIng Requirements May 2001 Description: SMIng should allow the definition of arrays of attributes. Motivation: Discussion: * 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 verbage 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. 3.40 Composition Status: new From: SMIng Description: SMIng must provide support for the composition of new compound types from more basic (potentially compound) types. Motivation: Simplifies the reuse attribute combination such as InetAddressType and InetAddress pairs. 3.41 Existence Constraints Status: new From: WG Description: SMIng must provide a mechanism to formally express existance constraints. Motivation: Existence constraints are already embedded in SMIv2 INDEX clauses and DESCRIPTION clauses. Westerinen, et. al. Expires November 12, 2001 [Page 19] Internet-Draft SMIng Requirements May 2001 3.42 Ordering Constraints Status: new From: WG Description: SMIng must provide a mechanism to formally express ordering constraints. Motivation: Discussion: * 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). 3.43 Attribute Transaction Constraints Status: 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 which need to be modified together (such as InetAddressType, InetAddress). Discussion: * 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 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? 3.44 Attribute Value Constraints Status: 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 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." Westerinen, et. al. Expires November 12, 2001 [Page 20] Internet-Draft SMIng Requirements May 2001 3.45 Associations Status: new From: WG Description: SMIng should provide mechanisms to explicitly specify associations. Motivation: Discussion: * 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. 3.46 Association Cardinalities Status: new From: WG Description: Cardinalities between associations should be formally defined. Motivation: 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. 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? Discussion: * See also David Putzolu's comment on issue #45. 3.47 Method Constraints Status: new From: WG Description: Method definitions must provide constraints on parameters. Motivation: Westerinen, et. al. Expires November 12, 2001 [Page 21] Internet-Draft SMIng Requirements May 2001 3.48 Table Relationships Status: new From: WG Description: SMIng should support REORDERS and EXPANDS clauses. Motivation: A REORDERS statement allows to swap indexing orders without having to redefine the whole table. An EXPANDS statement formally state that there is a 1:n existance relationship between tables. This information can be used by code generators to create more sensible implementation specific data structures. 3.49 Float Data Types Status: new From: WG, SMIng 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 not as an SMIng extension. Lesson learnt from the SMIv1/v2 debate about Counter64/Integer64/... Discussion: * 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. 3.50 Compliance and Conformance Status: 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. In SMIng we have the ability to express much of this information at the protocol-independent layer, this reducing redundant information. Some compliance or conformance information may be protocol- specific, therefore we also need the ability to express this information in the mapping. 3.51 Categories of Modules Status: new From: Individual Description: The SMIng documents should give clear guidance on which kind of information (wrt generality, type/class/extension/..) should be put in which (kind of a) module. Motivation: E.g., in SMIv2 we don't like to import Utf8String from Westerinen, et. al. Expires November 12, 2001 [Page 22] Internet-Draft SMIng Requirements May 2001 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. Bad experience with SMIv2. 3.52 Language Extensibility Status: new From: SMIng Description: The language should have characteristics, so that future modules can contain information of future syntax without breaking original SMIng parsers. Motivation: E.g., when SMIv2 introduced REFERENCEs it would have been nice if it would not have broken SMIv1 parsers. Achieve language extensibility without breaking core compatibility. 3.53 Length of Identifiers Status: should From: SMIng Description: The allowed length of the various kinds of identifers 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. 3.54 Why Are So Many SMIv1/v2 So Error Tolerant? Status: 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 excuse for errors and parser implementations become more consistent. (Who would expect that a C compiler is tolerant about a missing semicolon?) Discussion: * David H.: I think the reality of the situation is that developers write few mibs, but write much C code. There are Westerinen, et. al. Expires November 12, 2001 [Page 23] Internet-Draft SMIng Requirements May 2001 few developers who understand mib syntax, and I don't expect to see that improve even if we use a non-ASN.1 langauge, 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. 3.55 Core Language Keywords vs. Defined Identifiers Status: should From: SMIng 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 `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. 3.56 i18n Status: 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. Discussion: * 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. 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 Westerinen, et. al. Expires November 12, 2001 [Page 24] Internet-Draft SMIng Requirements May 2001 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. 3.57 Special Characters in Texts Status: new From: Individual Description: Allow an escaping mechanism to encode characters like double quotes or explicit NLs in texts like DESCRIPTIONs or REFERENCEs. Motivation: Otherwise, it's not possible to represent the contents of the SMIng `abnf' statement correctly: it can contain literal characters enclosed in double quotes. 3.58 Mapping Modules to Files Status: new From: SMIng 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. Discussion: * 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 Westerinen, et. al. Expires November 12, 2001 [Page 25] Internet-Draft SMIng Requirements May 2001 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. 3.59 Comments Status: should From: SMIng 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 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. 3.60 Simple Grammar Status: new From: SMIng 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. 3.61 Place of Module Information Status: should From: SMIng 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: Keep module information where it belongs. Discussion: * 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 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 Westerinen, et. al. Expires November 12, 2001 [Page 26] Internet-Draft SMIng Requirements May 2001 information, since the module itself is the appropriate container. 3.62 Fully Qualified Identifiers Status: should From: SMIng 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. 3.63 Readable Revision Date Representation Status: should From: SMIng Description: The SMI notation of revision dates consists of 11 or 13 characters, e.g. 199602282155Z, which is difficult to parse for humans. The trailing `Z' which represents GMT is superfluous, since no other timezone is allowed. Motivation: 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. Human readability of date and time information. 3.64 Make Status Information Optional Status: new From: SMIng 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. Discussion: * 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 Westerinen, et. al. Expires November 12, 2001 [Page 27] Internet-Draft SMIng Requirements May 2001 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 wrt 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/referenceing 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. 3.65 Units and Default Values of Defined Types Status: new From: SMIng 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 applicaple to defined types and format information should be applicable to attributes. Westerinen, et. al. Expires November 12, 2001 [Page 28] Internet-Draft SMIng Requirements May 2001 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. 3.66 Arbitrary Unambiguous Identities Status: basic From: SMI Description: SMI allows to use OBJECT-IDENTITIES to define unambiguous identies 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), although OIDs are probably not present in the core language. Motivation: SMI Compatibility. 3.67 Remove OIDs from the Core Language Status: new From: SMIng Description: While in SMI and SPPI definitions of attributes are bound to OIDs, SMIng should not use OIDs for the definition of classes, class 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. 3.68 Module Namespace Status: 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. Westerinen, et. al. Expires November 12, 2001 [Page 29] Internet-Draft SMIng Requirements May 2001 3.69 Problem: Where to Put Constraints Required by the Protocol? Status: new From: Individual Description: Some constraints have to be fulfilled in order to not violate protocol limitation. E.g., OIDs are limited to 128 sub- identifiers. If strings are proposed to be used for indexing, should their lengths be limited in the protocol neutral model or in the SNMP mapping? class Script { attribute String owner { ... }; // limit to 32 octets? attribute String name { ... }; // limit to 32 octets? ... unique (owner, name); }; snmp { table smScriptTable { oid smScriptObjects.3; index (owner, name); implements Script { object smScriptOwner owner; // limit to 32 octets? object smScriptName name; // limit to 32 octets? ... }; }; }; Motivation: [This is just an open question.] 3.70 Problem: Phrasing Descriptions Status: new From: Individual Description: It can be a real pain for SNMP people to (re)phrase DESCRIPTIONs in a protocol neutral way. Exercise: Try to rephrase this DESCRIPTION: ifTableLastChange OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time of the last creation Westerinen, et. al. Expires November 12, 2001 [Page 30] Internet-Draft SMIng Requirements May 2001 or deletion of an entry in the ifTable. If the number of entries has been unchanged since the last re- initialization of the local network management subsystem, then this object contains a zero value." ::= { ifMIBObjects 5 } Motivation: [This is just an open question.] 3.71 Problem: Mapping Protocol Specific Attributes Status: new From: Individual Description: Some attributes are only meaningful in a specific target domain, e.g., RowStatus in SNMP. They should not be specified in protocol neutral SMIng models. They have to be added to classes in the SNMP mapping module. This could be achieved by using inheritence: A protocol specific class can be inherited from the protocol neutral class adding the relevant RowStatus attributes in the SNMP mapping module. In the same module, the SNMP mapping is done based on the refined classes. Further problems can occur, when classes should be modeled this way that represent original SMIv2 tables that contain objects with mixed semantics, e.g. a RowStatus object that is (mistakenly) also used to represent a row's enabled/disabled status. Motivation: [This is just an open question.] 3.72 Hyphens in Identifiers Status: should From: SMIng 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. Motivation: SMIng should simply allow hyphens in all kinds of identifiers. No exceptions. Reduce confusion and exceptions. Requires, however, that implementation mappings properly quote hyphens where appropriate. Westerinen, et. al. Expires November 12, 2001 [Page 31] Internet-Draft SMIng Requirements May 2001 3.73 The Set of Spec Documents Status: new From: SMIng 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, independant of external specifications. Motivation: 3.74 Allow Refinement of All Definitions in Conformance Statements Status: 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 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. Prevent SMIv2 errata. Discussion: * 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. 3.75 Referencing a Group of Instances of a Class Status: align 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 (see draft-ietf-diffserv-pib-03.txt). SMI also uses these semantics without any formal notation (see Westerinen, et. al. Expires November 12, 2001 [Page 32] Internet-Draft SMIng Requirements May 2001 SNMP-TARGET-MIB in RFC2273). Discussion: * David H.: Is this already covered by #46 Association Cardinalitites? Do we need to separate the formal specification of cardinality from its use here for associations? 4. Conformance and Capability Reporting [TBD. See also reqs-00.] 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. Event: Occurrences which should be reported or which will result in a change of state. Index: (See "Instance Name.") Instance Name: One or more attributes of a class whose value(s) uniquely identify an instance. This is also known as an "index" or "key." Interface: (See "method signature.") Key: (See "Instance Name.") Method: The specification of a behavior or operation, having a specific signature, included in a class definition. Westerinen, et. al. Expires November 12, 2001 [Page 33] Internet-Draft SMIng Requirements May 2001 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. 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. 7. Acknowledgements Special thanks to Dave Durham, whose work on the original NIM (Network Information Model) draft was used in generating this document. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [3] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [4] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [5] , ., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1907, January 1996. [6] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. [7] White, K., "Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations", RFC 2925, September 2000. [8] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, S., Westerinen, et. al. Expires November 12, 2001 [Page 34] Internet-Draft SMIng Requirements May 2001 Sahita, R., Smith, A. and F. Reichmeyer, "Structure of Policy Provisioning Information (SPPI)", draft-ietf-rap-sppi-06.txt, April 2001. [9] 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. [10] Authors' Addresses Andrea Westerinen Cisco Systems 725 Alder Drive Milpitas, CA 95035 USA EMail: andreaw@cisco.com Chris Elliott Cisco Systems 7025 Kit Creek Road Research Triangle Park, NC 27709 USA EMail: chelliot@cisco.com Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany Phone: +49 531 391-3289 EMail: schoenw@ibr.cs.tu-bs.de URI: http://www.ibr.cs.tu-bs.de/ Westerinen, et. al. Expires November 12, 2001 [Page 35] Internet-Draft SMIng Requirements May 2001 Frank Strauss TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany Phone: +49 531 391-3266 EMail: strauss@ibr.cs.tu-bs.de URI: http://www.ibr.cs.tu-bs.de/ Jamie Jason Intel Corporation MS JF3-206 2111 NE 25th Ave. Hillsboro, OR 97124 USA EMail: jamie.jason@intel.com Walter Weiss Ellacoya Networks 7 Henry Clay Dr. Merrimack, NH. 03054 USA EMail: wweiss@ellacoya.com Westerinen, et. al. Expires November 12, 2001 [Page 36] Internet-Draft SMIng Requirements May 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. Westerinen, et. al. Expires November 12, 2001 [Page 37]