The 7th NMRG meeting was held in Schloss Kleinheubach from 6-8 September 2000. The participants were (in alphabetic order): HD Heiko Dassow (T-Nova) DD David Durham (Intel) KM Keith McCloghrie (Cisco) JS Juergen Schoenwaelder (TU Braunschweig) FS Frank Strauss (TU Braunschweig) BW Bert Wijnen (Lucent) *arrived later* The local host of the meeting was T-Nova, the research and development devision of Deutsche Telekom. T-Nova provided excellent meeting facilities and the overall organization was of high quality. In fact, T-Nova set a new milestone as a local host which will be hard to top. The following minutes summarize the intensive discussions during the 7th NMRG meeting. The minutes do not always strictly follow the chronological order to keep the topics organized. The minutes were compiled by JS from notes taken by JS and DD. 0. Summary The meeting started with an attempt to identify the feature differences between SPPI, SMIng and the current SMIv2. Afterwards, the participants collected a list of new features that could be added to a future SMI which resulted in a kind of a wish-list. The rest of the meeting was spent discussing each feature in detail in order to understand whether it is feasible and useful to support it in a future SMIng revision. Some time was spent at the end of the meeting to discuss how to make progress on incorporating the accepted new features in the next SMIng revision and to assign tasks to volunteers. 1. SPPI and SMIng Differences from SMIv2 New features in the SPPI: + EXTENDS keyword for sparse table augmentations + UNIQUENESS clause to identify set of columns that uniquely identify a row + PIB-REFERENCES clause to type references to other tables + SUBJECT-CATEGORIES to identify sets of related PIB modules + PIB-INDEX clause to identify the COPS instance identification + Unsigned64 and Integer64 base types + PIB-ACCESS instead of MAX-ACCESS clauses + PIB-MIN-ACCESS instead of MIN-ACCESS clauses + INSTALL-ERRORS clause to define specific error codes for row creation + New TCs for instance identification and references ("pointers") + PIB-TAG clause for identifying a tag target column with tag references - no scalars - no Counter32, Counter64, Gauge32, Opaque - no object access clauses - no notifications - no agent capabilities (left for further study) New features in the SMIng: + all table existence relationships (augments, expands, extends, reorders) + Unsigned64 and Integer64 base types + Float32, Float64 and Float128 base types based on IEEE floating point types + Type system allows to derive types from existing types + single group statement replaces OBJECT-GROUP and NOTIFICATION-GROUP macros + create statement instead of read-create access mode + new syntax based on a small set of core syntax rules + language extensibility mechanism + annotation mechanism + constraints on statement ordering to reduce the number of forward references to the required minimum + units/format/default statements on type and column definitions + implied status current if status statement is absent + removes redundant SEQUENCE statements for table row definitions + redefines some previous base types (e.g. Counter32) as derived types + deprecates IpAddress (now a derived type) - no agent capabilities (left as an extension) A quick discussion revealed that the current create statement in SMIng may be problematic as there is currently no way to lower the create requirement in a compliance statement. Another issue raised was to require from a MIB compiler the (perhaps selected) understanding of extensions. Comments were made to make the SMIng syntax even less verbose. Some attendees expressed that they dislike the fact that SMIng has no equivalent to the SEQUENCE definition since they help human readers to gain an overview of a table definition. 2. Feature Wishlist o structured types o discriminated unions o arrays o nesting of structured types o required support of language extensions o handling of possible annotation conflicts o templates for reoccurring definitions (RMON example) o implied OID assignments o objects instead of tables/rows o support for explicit inheritance o multiple inheritance o constraints on possible combinations of values etc. o instance identification for multiple protocols that use different naming schemes without enforcing a global naming system o explicit support for associations (cardinality, ...) o containment (which may imply that classes act as types) o logical groupings (similar to SPPI subject categories) o methods/operations o readjust compliance and capabilities definitions 3. Feature Discussion 3.1 Classes (aka templates) There seem to be many MIB tables which need similar columns. RMON2 control tables are one example. Another example is the typical RowStatus, StorageType, OwnerString triple being used in many tables. Templates may be a way to define such combinations once and to use them when needed. Note that templates itself must specify descriptors. Templates seem to be truly useful only if they are used with multiple attributes. A question was whether the same thing can be achieved in principal with complex types. The answer was that complex types provide atomic access while templates provide only attribute specific atomic access. An issue was raised whether templates make generic tables with table extensions (such as the ifTable) less likely to appear since it is too easy to just instantiate an ifTable template. This potential misuse may be addressed by proper education. Another question raised was how templates relate to the concept of sub-classing in an OO world. Later during the meeting, it was observed that templates are in fact classes and nested templates (classes) represent inheritance while table extensions are purely instance specific and not the same as inheritance. The following observations were made: - Table extensions are useful if you need a common place where instances exist. For example, it is very useful to have all interfaces listed in the ifTable and to provide extension tables for interface type specific details. On the other hand, it does not seem to be useful to have a common place where all RowStatus and StorageType objects are listed (since this would put severe constraints on the table indexing schemes). - Classes (templates) are useful if you do not want a common place where all instances exist, but you still want to introduce a common structure across many MIBs. This common structure makes MIB definitions more compact and provides valuable information to code generators that understand the semantics associated with certain classes. - Structured types (like DateAndTime) make sense if you never have to access the elements of the structured type separately. In other words, structured types means atomic access with an internal structure. DD provided the following example how classes (templates) may help to provide reusable OO definitions that are later mapped to a tabular repository structure for use with SNMP and COPS: class A { attribute a1 {...}; ... }; class B : A { attribute b1 {...}; ... }; table Y { implements B (a1, ..., b1, ...); extends table X; create (...); oid xxx.42; }; Note that the implements statement requires to list the attributes that are actually implemented. The order of the attribute list can be used to automatically assign OID values. Note well that class definitions can be imported and hence it is possible that class and table definitions evolve at different speeds. 3.2 Containment Containment of classes is another concept that seems to be very valuable. The first example used during the meeting was that of a Rectangle class which contains several Points to define the rectangle: class Point { attribute x { ... }; attribute y { ... }; ... }; class Rectangle { attribute Point A { ... }; attribute Point B { ... }; ... }; table YY { implements Rectangle (A.x, A.y, B.x, B.y); index (A.x, A.y, B.x, B.y); ... } Note that it is necessary to "flatten" the containment hierarchy when mapping the classes into a tabular structure, which means that we need to have a hierarchical naming scheme at least in the class layer. Another less abstract example was provided by DD which combines inheritance and containment: class Subnet { attribute inetAddress { ... }; attribute inetPrefix { ... }; }; class PortRange { attribute startPort { ... }; attribute endPort { ... }; }; class BaseFilter { attribute filterName { ... }; attribute byteCount { ... }; attribute packetCount { ... }; }; class FiveTupleFilter : BaseFilter { attribute Subnet srcSubNet { ... }; attribute Subnet dstSubNet { ... }; attribute PortRange srcPortRange { ... }; attribute PortRange dstPortRange { ... }; attribute protocol { ... }; }; table FilterTable { implements FiveTupleFilter ( filterName, byteCount, packetCount, srcSubNet.inetAddress, srcSubNet.inetPrefix, dstSubNet.inetAddress, dstSubNet.inetPrefix, srcPortRange.startPort, srcPortRange.endPort, dstPortRange.startPort, dstPortRange.endPort, protocol); index (filterName); ... }; 3.3 Types SMIng extends the SMIv2/SPPI type system by allowing new types to be derived from existing types. Other frequently suggested features are structured types, discriminated unions and arrays. It was recognized that whatever addition made to the SMIng language should honor the fact that compound types must be restricted in size and that compound types only make sense where atomic access to the data is required. In other words, containment should be used as much as possible if no atomic access is needed. Structured types are generally considered to be worthwhile to add. We already have structured types (such as DateAndTime) but we simply lack a good mechanism to define them in a machine readable way. MIB authors sometimes use DISPLAY-HINTS to fill this niche. The question was raised whether it is needed to support nesting of structured types. Disallowing nested structured types may help to put bounds on the complexity of compound types and to force people to use containment for real complex things. Another issue was the encoding of compound types. One way to encode compound types is to use ASN.1/BER rules. Another one would be to use a more lightweight set of encoding rules that encode fixed length numbers in network byte order, which is typically what existing structured types such as DateAndTime already use. An argument was made that a set of lightweight encoding rules is a better approach since these types are usually dealt with in application code where programmers are usually not aware of ASN.1/BER functions. This reflects a separation between application specific types (defined by the SMIng) and the core protocol data types. Discriminated unions are only needed in some special cases. However, in these cases (generic network addresses, distributed management MIBs), not having discriminated unions is rather painful. It seems to be worthwhile to support discriminated unions if it is possible to support them without major additions in complexity. There was agreement that arrays are not really needed and that they are hard to get right given the constraints imposed by the SNMP protocol. 3.4 Instance Identification SNMP and COPS-PR have different instance identification schemes. Other protocols that might use SMIng may introduce even more instance identification schemes. The SMIng specification should therefore separate instance identification from the set of reusable data definitions and provide instance identification specific mechanisms in the mappings to certain repository structures. 3.5 Methods The addition of general methods to the SMIng is controversial. Methods need to have well defined transactional semantics to be useful. The general use of methods may imply RPC-like procedures to be defined in the SMIng syntax. The primary target protocols SNMP and COPS-PR do not provide support for method invocations. So adding support for methods into SMIng at this point in time may turn out to be a hard problem to solve if this requires to also enhance protocols. However, it may as well be possible to implement RPC style method calls on top of a data model technology. JS pointed out that the SPPI install/remove access resembles constructor/destructor methods in OO systems (or create/delete operations in CMIP). Furthermore, SNMP MIBs lack a mechanism to define signatures for typical set operations. The fact that an SNMP set can carry varbinds in any obscure order adds significant complexity, raises implementation costs and handicaps interoperability. Being able to at least define signatures for typical set operations may be very valuable (although it may lead to a situation where people do not implement the full set semantics required by the SNMP specifications). It seems there are several ways to proceed: (i) Solve the method problem and constructors/destructors fall out as special cases. (ii) Solve the constructors/destructors case and leave generic methods for a future extension/revision (when the protocols are ready to support them). (iii) Solve the constructors/destructors case and provide some support (e.g. signatures for write operations) on top of a pure data definition model. (iv) Only provide protocol specific hooks so that the handling of methods and constructors/destructors is a pure protocol specific subject. It seems that (iv) is not a very desirable solution. Some more time was spent on constructors. It was noted that the SMI read-create access is really a combination of read-write for the particular column and create for the whole table/row. SMIng reflects this by introducing a create statement and removing the read-create access mode. It may be reasonable to extend the SMIng create statement and to map it into protocol specific mechanisms (COPS-PR install and SNMP RowStatus, perhaps with a well defines signature). The create statement should also define the create specific error conditions (which maps to SPPI's INSTALL-ERRORS clause). A similar mechanism may be needed for destructors (e.g. a delete statement) since a separate delete may be required in cases where instances are created by the managed device and it is only possible to delete them via management operations. 3.6 Relationships SMIng provides explicit keywords to identify all the table existence relationships. SPPI provides only the subset that makes sense for SPPI since COPS-PR does not support complex instance identifications. In addition to table existence relationships, there are a number of inter-table relationships usually represented by using some sort of pointers. SPPI introduces "typed" pointers in the form of references to table entries, where the PIB-REFERENCE clause defines the target table. This allows to express n:0..1 relationships. SPPI also introduces tag lists, where the PIB-TAG clause identifies the attribute being pointed to. This allows to express n:m relationships with the additional constraint that a tagged instance can only belong to exactly one tag list. The SNMP target MIB introduced a tagging mechanism for n:m relationships where a tagged instance can belong to multiple tag lists. In the subsequent discussion, issues were raised about the data type being used to build tag lists: strings versus numbers versus instance identifications (numbers in COPS-PR or OID fragments in SNMP). But this is basically a type issue which is independent of the data definition language - so it seems to be sufficient to have mechanisms in place which allow to properly constrain a pointing attribute to another table or columns within a table. It was not clear whether SMIng should establish additional constraints for pointer/tagging types to prevent people from using dynamic values such as ifOperStatus value up(1) as a tag to refer to all active interfaces. The conclusion was that SMIng should support mechanisms for constrained pointers to represent inter-table relationships and a set of associated type definitions that provide suitable semantics. 3.7 Constraints Constraints are a general mechanism to make specifications more precise. It was noted that the SMIng language (as well as SMIv2 and SPPI languages) already covers some constraints. However, it is possible to define even more constraints, such as constraints between attribute values or constraints on the existence of certain instances. It was also noted that trying to be too precise is sometimes causing headaches when the modeled technology evolves over time. The SMIv2 rules are actually often bended because definitions (e.g. size and range constraints) are sometimes too restrictive. Other proposals that are related to the concept of constraints try to express machine readable information which can be used to divide the states reported by a MIB module into good and bad states. A well-known constraint language is the object constraint language (OCL) which is part of the UML effort. During the discussion, a number of useful constraints were identified and it turned out to be unclear whether OCL can actually express them. The general conclusion was that constraints and a potential interface to an OCL like language may be useful but needs much more research. 3.8 Subject Categories There was a discussion on the concept of subject categories introduced by the SPPI. One of the questions raised was how subject categories relate to SNMP contexts. It turns out that SNMP contexts are not precisely defined. In particular, SNMP contexts do not seem to require that context spaces are separated. It seems to be possible that instances can exist in multiple contexts at the same time. Subject categories require "non-shared" instances. Looking at it from a COPS-PR perspective, subject categories are a mechanism to avoid figuring out dynamically at runtime which client-type to use. It also seems useful to assign subject categories statically (at compiler-time). Otherwise, if they were defined at "run-time", it would be very hard to write applications (e.g., PDP applications) because the application-writer wouldn't know in advance what selection of PIB modules would be accessible to his application. The subsequent discussion revealed that subject categories have a global name space and that assigning values and labels in PIB modules rather than a centralized place may turn out to cause serious problems. It is also unclear how the concept of subject categories will be used in practice and how many of them will be introduced. Establishing a central registry for subject categories may work fine for the IETF - but it may be problematic for vendor specific subject categories. The argument for assigning subject categories in PIB modules was that a compiler can easily detect the omission of an assignment. The discussion stopped without clear results. The SPPI folks probably want to think more about this concept and alternate assignment or identification mechanisms. IANA may be a way out to get at least non-conflicting number and label assignments. 4. Plan of Actions A discussion was held about the appropriate set of documents needed to define SMIng and the mappings to at least COPS-PR and SNMP. The proposed set of documents looks as follows: (1) SMIng Language Specification The specification of the language, including the ABNF for the syntax and a textual description of each language feature. (2) Common SMIng Definitions Common definitions of core data types and core classes. It seems useful to separate them from the language specification itself since some (e.g. RowStatus) may have lengthy descriptions. (3) Guidelines for Using SMIng Since SMIng offers many new features, there is a need to have a document which helps to educate authors of SMIng modules on how to use them. A set of good examples should go into this document. (4) SMIng Mapping to SNMP This document defines how SMIng data definitions can be used with the SNMP protocol. (5) SMIng Mapping to COPS-PR This document defines how SMIng data definitions can be used with the COPS-PR protocol. In addition, it may be desirable to define an XML SMIng exchange format, based on the DTD proposed in . Such a format can be optimized to machine readability while the SMIng syntax is optimized to be concise and human friendly. In order to make progress on SMIng, the following plan of actions was agreed upon: (a) JS writes up minutes and circulates them within a week (b) FS will take the lead to come up with an updated syntax for SMIng. A first proposal should appear within two weeks. (c) Once the syntax is available, DD will work out examples that can help to identify open issues and which will be a basis to better communicate core SMIng ideas. (d) KM will help JS and FS to write parts of the SMIng specification starting 4 weeks after the NMRG meeting (when he is back from vacation). (e) The ID cutoff for the December IETF is expected to be early November, depending on the rules for new IRTF documents.