[nmrg] minutes from the 7th NMRG meeting

[Juergen Schoenwaelder <[e-mail]>]

Below are the minutes from the 7th NMRG meeting in Kleinheubach.

/js

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 <draft-irtf-nmrg-smi-xml-00.txt>.
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.