Subject: Re: [nmrg] First thoughts on new SMIng grammar
From: "David T. Perkins" <[email-masked]>
To: Harald Alvestrand <[email-masked]>, Frank Strauss <[email-masked]>, [email-masked]
Date: Wed, 27 Sep 2000 10:44:17 -0700

HI,

Lets first talk about something that we DO NOT want.

I believe that one of the major failings of CMIP was that
it allowed (and encouraged) MIB designers to create new
data types. This had the really bad cost of requiring
agents and management applications to be "recompiled"
to support a new data type. For example, if you had
a MIB browser and you got a new MIB module with new data
types, you would have to recompile to support the data
type. This was because the "on the wire" encodings were
extended. This was also needed to support filters!
Also, I've seen CMIP MIB definitions that had choice
inside choice inside choice. It looked like
the MIB designer tried to support everything in one
definition. (From the examples I saw, this was the worst
in action and notification data.) Trying to understand
definitions with complex choices is really difficult,
and I don't remember a language that does a good job
with this.

Please note that I do wish that we had more "complex" types,
and a complete set of base types. For example, I wish there
was the type "sequence" (not sequence of). However, I believe
that it would abused if it was not documented properly.

The name-space issue is important and should be solved.
However with it comes the "version control" issue.

Just a few responses...

Regards,
/david t. perkins

At 11:44 AM 09/27/2000 +0200, Harald Alvestrand wrote:
>thoughts, please ignore if already trashed to death:
>
>- do we want complex types?
>we could formalize the link between address type and address (for instance) 
>by declaring a construct group, which would instantiate to 2 MIB variables.
>probably make a default mapping to <oid>.1 and <oid>.2 with an override 
>capability to be able to represent older MIBs
>
>- do we want polymorphic types, where types inherited from the same base 
>type can have different representations?
>
>- do we want abstract types, which do not specify their format?
>
>- do we want to muck around with namespace? The excessive number of "naming 
>conventions" in old SMI indicates to me either a lack of more powerful 
>notational tools or a lack of proper namespace management.
>
>sniping from the sidelines, just passing by.....
>
>           Harald
>
>

Date: Wed, 27 Sep 2000 15:10:16 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: [nmrg] First thoughts on new SMIng grammar
Sender: [email-masked]
Status: O
Content-Length: 2674
Lines: 59

>>>>> Harald Alvestrand writes:

Harald> thoughts, please ignore if already trashed to death:

Harald> - do we want complex types?  we could formalize the link
Harald> between address type and address (for instance) by declaring a
Harald> construct group, which would instantiate to 2 MIB variables.
Harald> probably make a default mapping to <oid>.1 and <oid>.2 with an
Harald> override capability to be able to represent older MIBs

This is more or less what we have in mind. See the class InetEndpoint
in the example Frank posted to this list. This groups an
InetAddressType and an InetAddress together. Note that the OID
assignement is a matter of the mapping of the InetEndpoint class 
into an SNMP table.

Harald> - do we want polymorphic types, where types inherited from the
Harald> same base type can have different representations?

Harald> - do we want abstract types, which do not specify their
Harald> format?

In the example, we have derived InetAddressIPv4 and InetAddressIPv6
from InetAddress (which is again derived from OctetString). So
InetAddress more or less acts as a base type for IPv4 and IPv6
addresses. So an InetAddress is abstract in the sense that it is
silent about a version specific address format. And it is polymorphic
in the sense that derived types can define different representations.

Harald> - do we want to muck around with namespace? The excessive
Harald> number of "naming conventions" in old SMI indicates to me
Harald> either a lack of more powerful notational tools or a lack of
Harald> proper namespace management.

there has always been the policy that identifiers should be unique so
that you can just refer to a short name and everybody knows what is
meant. Hence we have all the prefixes to make descriptors globally
unique. Furthermore, many names are used carry additional semantics
(e.g. where a points to) because there are no better ways to express
these things. Finally, there is the rule that everything is
implicitely exported - which implies that you choose long names just
to avoid any name clashes.

In other words: I think that we need not fundamentally change the
namespaces concept. But we need to re-consider some language features
such as "everything is implicitly exported" in order to get rid of
some of the reasons that have lead to the excessive number of "naming
conventions" in the past.

Thanks for your feedback.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

Date: Wed, 27 Sep 2000 11:44:00 +0200
To: Frank Strauss <[email-masked]>, [email-masked]
From: Harald Alvestrand <[email-masked]>
Subject: Re: [nmrg] First thoughts on new SMIng grammar
Sender: [email-masked]
Status: O
Content-Length: 815
Lines: 22

thoughts, please ignore if already trashed to death:

- do we want complex types?
we could formalize the link between address type and address (for instance) 
by declaring a construct group, which would instantiate to 2 MIB variables.
probably make a default mapping to <oid>.1 and <oid>.2 with an override 
capability to be able to represent older MIBs

- do we want polymorphic types, where types inherited from the same base 
type can have different representations?

- do we want abstract types, which do not specify their format?

- do we want to muck around with namespace? The excessive number of "naming 
conventions" in old SMI indicates to me either a lack of more powerful 
notational tools or a lack of proper namespace management.

sniping from the sidelines, just passing by.....

           Harald

From: Frank Strauss <[email-masked]>
To: [email-masked]
Subject: [nmrg] First thoughts on new SMIng grammar
Date: 20 Sep 2000 18:25:30 +0200
Sender: [email-masked]
Status: O
Content-Length: 7915
Lines: 266

Hi!

As expressed on the last meeting, I played with some examples of
MIB/PIB fragments to get a first feeling on how a new grammar could
look like. I think that it's not yet reasonable to define a formal
ABNF grammar at this point in time. Today, Juergen and I discussed
some first details and below is what we have now as a first proposal
on type definitions, unions, class definitions, class inheritance,
containment, and mappings to target architectures.

Don't expect too much. There are lots of `...' and concepts not yet
handled (structured types, annotations, compliance statements, ...)

We think that the conversion of more real world MIBs and PIBs could
help significantly.  David, maybe you find time to pick a `well
known' PIB and try to write its contents down in the grammar that
you have mind after reading the examples below. Juergen and I will
do the same for a well known MIB, presumably the IF-MIB.

I'll be on vacation until the end of this month. I hope this can
help to make progress during the next days.

 Frank

typedef InetPort {
    type            Unsigned32(0..65535);
    description     
       "Represents an Inet port number.";
};

typedef InetProtocol {
    type            Unsigned32(0..255);
    description     
       "Represents an Inet protocol number.";
};

typedef InetAddress {
    type            OctetString;
    description     
       "Represents an arbitrary InetAddress.";
};

typedef InetPrefixLen {
    type            Unsigned32;
    description     "...";
};

typedef InetAddressIPv4 {
    type            InetAddress (4);
    format          "1d.1d.1d.1d";
    description     
       "Represents an IPv4 network address:
        
        octets   contents         encoding
         1-4     IP address       network-byte order
        
        If there is a corresponding InetAddress.type attribute
	its value is ipv4(1).";
};

typedef InetPrefixLenIPv4 {
    type            InetPrefixLen(0..32);
    description     "...";
};

typedef InetAddressIPv6 {
    type            InetAddress (16 | 20);
    format          "2x:2x:2x:2x:2x:2x:2x:2x%4d";
    description     
       "Represents an IPv6 network address:
        
        octets   contents         encoding
         1-16    IPv6 address     network-byte order
        17-20    scope identifier network-byte order
        
        If there is a corresponding InetAddress.type attribute
	its value is ipv6(2).
        
        The scope identifier (bytes 17-20) MUST NOT be present
        for global IPv6 addresses. For non-global IPv6 addresses
        (e.g. link-local or site-local addresses), the scope
        identifier MUST always be present. It contains a link
        identifier for link-local and a site identifier for
        site-local IPv6 addresses.
        
        The scope identifier MUST disambiguate identical address
        values. For link-local addresses, the scope identifier will
        typically be the interface index (ifIndex as defined in the
        IF-MIB, RFC 2233) of the interface on which the address is
        configured.
        
        The scope identifier may contain the special value 0
        which refers to the default scope. The default scope
        may be used in cases where the valid scope identifier
        is not known (e.g., a management application needs to
        write a site-local InetAddressIPv6 address without
        knowing the site identifier value). The default scope
        SHOULD NOT be used as an easy way out in cases where
        the scope identifier for a non-global IPv6 is known.";
};

typedef InetPrefixLenIPv6 {
    type            InetPrefixLen(0..128);
    description     "...";
};

typedef InetAddressDNS {
    type            InetAddress (1..255);
    format          "255a";
    description     
       "Represents a DNS domain name. The name SHOULD be
        fully qualified whenever possible.
        
        If there is a corresponding InetAddress.type attribute
	its value is dns(16).
        
        The descriptions of objects of this type must fully describe
        how (and when) such names are to be resolved to IP
        addresses.";
};

class InetEndpoint { // conflicting namespaces of classes/types ?
    attribute type {
        type        Enumeration(unknown(0), ipv4(1), ipv6(2), dns(16));
	access      readwrite;
        description
	       "A value that represents a type of Internet address.
	 
		unknown(0)  An unknown address type. This value MUST
			    be used if the value of the corresponding
			    address object is a zero-length string.
			    It may also be used to indicate an IP address
			    which is not in one of the formats defined
			    below.
	 
		ipv4(1)     An IPv4 address as defined by the
			    InetAddressIPv4 type.
	 
		ipv6(2)     An IPv6 address as defined by the
			    InetAddressIPv6 type.
	 
		dns(16)     A DNS domain name as defined by the
			    InetAddressDNS type.
	 
		The type SHOULD NOT be subtyped in object type definitions
		to support future extensions. It MAY be subtyped in
		compliance statements in order to require only a subset of
		these address types for a compliant implementation.";
    };
    attribute InetAddress address {
	typemap type {
	    map ipv4 InetAddressIPv4,
	    map ipv6 InetAddressIPv6,
	    map dns  InetAddressDNS
	};
        access      readwrite;
        description
	       "Denotes a generic Internet address.
		
		An address value is always interpreted within the
		context of the type value. The type attribute defines
		the context.";
    };
};

class Subnet {
    attribute InetEndpoint inetAddress {
	// class       InetEndpoint;  // keyword `class' or `type'?
        description "...";
    };
    attribute InetPrefixLen prefixLen {
        // type        Unsigned32;
	typemap	inetAddress.type {
	    map ipv4 InetPrefixLenIPv4;
	    map ipv6 InetPrefixLenIPv6;
        }
	access      readwrite;
        description "...";
    };
};

class PortRange {
    attribute InetPort start {
	access	    readwrite;
	description "...";
    };
    attribute InetPort end {
	access	    readwrite;
	description "...";
    };
};

class BaseFilter {
    attribute DisplayString name {
	access	    readwrite;
	description "...";
    };
    attribute Counter64 byteCount {
	access	    readonly;
	description "...";
    };
    attribute Counter64 packetCount {
	access	    readonly;
	description "...";
    };
};

class FiveTupleFilter : BaseFilter {
    attribute SubNet srcSubNet {
	description "...";    // description optional?!
    };
    attribute SubNet dstSubNet {
	description "...";
    };
    attribute PortRange srcPortRange {
	description "...";
    };
    attribute PortRange dstPortRange {
	description "...";
    };
    attribute InetProtocol protocol {
	access      readwrite;
	description "...";
    };
};

// target architecture specific mappings

snmp filterMib {
    oid mib-2.xxx;
    table filterTable {
	oid filterMib.42;
	index (filterName);
	implements FiveTupleFilter {
	    column filterName         name;       // implicit oid: foo.42.1.1
	    column filterBytes        byteCount;
	    column filterPackets      packetCount;
	    column filterSrcType      srcSubNet.inetAddress.type;
	    column filterSrcAddress   srcSubNet.inetAddress.address;
	    column filterSrcPrefixLen srcSubNet.prefixlen;
	    column filterDstType      dstSubNet.inetAddress.type;
	    column filterDstAddress   dstSubNet.inetAddress.address;
	    column filterDstPrefixLen dstSubNet.prefixlen;
	    column filterSrcPortStart srcPortRange.start;
	    column filterSrcPortEnd   srcPortRange.end;
	    column filterDstPortStart dstPortRange.start;
	    column filterDstPortEnd   dstPortRange.end;
	    column filterProtocol     protocol;
	};
	description     "...";
    };  

    scalars filterStats {
        ...
    };
};

cops filterPib {
    oid xxx.yyy;
    table filterTable {
        ...
    };
};

diameter ...

Date: Wed, 20 Sep 2000 18:21:39 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] new mailing list members
Sender: [email-masked]
Status: O
Content-Length: 766
Lines: 19

I have added Keith McCloghrie and David Durham to the NMRG list so
that we can use this mailing list to work on some more SMIng details.

Frank has made some progress on the syntactic aspects. We also found a
number of new issues in the details - as expected. I am currently
researching work on object-relational database systems and more
specifically ODMG <URL:http://www.odmg.org/>. This seems very closely
related and we may want to borrow ideas/inspirations from that area.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

Date: Tue, 19 Sep 2000 17:36:54 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] minutes from the 7th NMRG meeting
Sender: [email-masked]
Status: O
Content-Length: 21532
Lines: 552

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.

From: "J.P. Martin-Flatin" <[email-masked]>
To: [email-masked]
Reply-To: "J.P. Martin-Flatin" <[email-masked]>
Subject: Re: [nmrg] Common Information Structure 
Date: Tue, 05 Sep 2000 14:31:45 +0200
Sender: [email-masked]
Status: O
Content-Length: 1216
Lines: 38

On Mon, 04 Sep 2000 23:53:36 -0700, "David T. Perkins" wrote:
> 
> The document looks like an updated and "politically correct" version
> of ASN.1. Why recycle an approach that has failed to live up to
> its potential.

Please find below an element of answer.

JP

>From: "Rutt, T E (Tom)" <[email-masked]>
>Cc: [email-masked], [email-masked]
>Subject: RE: Common Information Structure document
>Date: Tue, 29 Aug 2000 15:50:01 -0400
>
>I was asked by the TMF to be a liaison to the OMG
>on some of these data representation subjects.
>
>It turns out the TMF (TeleManagement Forum) is a firm
>believer in UML for writing Specificaitons which are neutral
>with respect to the underlying communication paradigm (e.g., 
>CORBA vs, CMIP, vs. XML etc).
>
>They have a need for data types to use in signatures for
>UML operations which are not strictly tied to CORBA IDL.
>
>Thus they want a profile for UML , which defines generic
>data types. Their example, in the liaison, is based on ASN.1.
>
>I think they would like the ADTF to look at the spec, and to
>give the TMN guidance on how to form a profile for UML in this
>subject area.
>
>Tom Rutt
>Lucent Technologies
>Tel: _1 732 949 7862
>email: [email-masked]

Date: Tue, 05 Sep 2000 00:35:33 -0700
To: Andy Bierman <[email-masked]>, Juergen Schoenwaelder <[email-masked]>
From: "David T. Perkins" <[email-masked]>
Subject: Re: [nmrg] Re: sming/sppi/smiv2 integration meeting details
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Status: O
Content-Length: 3153
Lines: 84

HI,

I agree and support Andy's view, and unfortunately work commitments
are keeping me away. Sorry.

Regards,
/david t. perkins

At 09:04 AM 09/01/2000 -0700, Andy Bierman wrote:
>Hi Juergen,
>
>> 
>> >>>>> Keith McCloghrie writes:
>> 
>> Keith> So,
>> 
>> Keith> option b) would be best, if you can resolve it quickly.
>> Keith> option c) would be OK, if it's within driving distance.
>> 
>> I have worked hard on option b) and I finally got very friendly help
>> from T-Nova, the research organization of the Deutsche Telekom. They
>> arranged a meeting room for us in some conference facilities which are
>> located in a castle at the Main river about a hour drive from the
>> Frankfurt airport. So here are the details:
>> 
>
>I am not going to be able to attend this meeting, but I appreciate
>the invitation very much.  As I emphatically stated at the NIM BOF,
>I am strongly in favor of this work.  I don't really agree with Keith
>that it is independent of the NIM effort, but I do agree that
>this work is long overdue, and a WG should be formed ASAP.
>(Maybe that's what Keith meant :-) 
>
>Maybe I could attend the next meeting, hopefully a WG meeting
>at IETF #49 in San Diego.
>
>Andy
>
>>    Tagungshotel Schloss Kleinheubach
>>    Schlosspark 1
>>    63924 Kleinheubach
>>    Germany
>> 
>>    Tel. +49 9371 401-0
>>    Fax. +49 9371 401 107
>>    email <[email-masked]>
>> 
>> A very nice photo of the location can be found here:
>> 
>>     <URL:http://www.untermain-online.de/schloss-kleinheubach/>
>> 
>> I have reserved a few rooms in the hotel so that we can actually stay
>> over night in the castle. The rates are very reasonable - about 100 DM
>> which amounts to roughly US $ 50 these days. Please contact the hotel
>> and tell them when you will arrive and how long you are going to
>> stay.
>> 
>> If you experience any problems with the room reservation or you have
>> any other urgent question, you can as well contact Uli Gruen
>> <[email-masked]> from T-Nova who did a great job of organizing
>> this nice meeting place for us.
>> 
>> The web page has a map (under "Anreise") which explains how you reach
>> Kleinheubach from Frankfurt airport by car. The meeting place is
>> directly located at the street B 469. So from the airport, just take
>> highway <3>.  Leave at the exist "Stockstadt" and take the B 469 south
>> until you reach Kleinheubach. The whole trip should not take more than
>> an hour.
>> 
>> You can find all this information including the map and the picture on
>> <URL:http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2000/kleinheubach/>
>> in case the other URL does not work for you.
>> 
>> Sorry that it took so long to get the meeting location finalized. If
>> you are interested, then I can tell you the whole story over a beer or
>> a glass of wine next week.
>> 
>> /js
>> 
>> --
>> Juergen Schoenwaelder      Technical University Braunschweig
>> <[email-masked]>  Dept. Operating Systems & Computer Networks
>> Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
>> Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

Date: Mon, 04 Sep 2000 23:53:36 -0700
To: "J.P. Martin-Flatin" <[email-masked]>, [email-masked]
From: "David T. Perkins" <[email-masked]>
Subject: Re: [nmrg] Common Information Structure
Sender: [email-masked]
Status: O
Content-Length: 789
Lines: 28

HI,

The document looks like an updated and "politically correct" version
of ASN.1. Why recycle an approach that has failed to live up to
its potential.

Regards,
/david t. perkins

At 04:09 PM 08/29/2000 +0200, J.P. Martin-Flatin wrote:
>>Date: Fri, 25 Aug 2000 17:35:14 -0400
>>To: [email-masked], [email-masked]
>>From: Andrew Watson <[email-masked]>
>>Subject: Common Information Structure document
>>
>>Good Afternoon,
>>
>>We have received a document from Telemanagement Forum describing the Common
>>Information Structure methodology they have developed for use in
>>protocol-neutral modelling. It has been filed as document ad/00-08-13:
>>
>>     http://cgi.omg.org/cgi-bin/doc?ad/00-08-13
>>
>>                             Regards,
>>
>>                                  Andrew
>

From: Keith McCloghrie <[email-masked]>
Subject: [nmrg] Re: sming/sppi/smiv2 integration meeting details
To: [email-masked] (Durham, David)
Date: Fri, 1 Sep 2000 12:23:46 -0700 (PDT)
Cc: [email-masked] ('Juergen Schoenwaelder'), [email-masked], [email-masked], [email-masked] (Durham David), [email-masked], [email-masked]
Sender: [email-masked]
Status: O
Content-Length: 3043
Lines: 85

I'll be there too.  Thanks for your hard work, Juergen.

Keith.
 
> Very good. I will be there.
> Thanks Juergen,
> -Dave
> 
> > -----Original Message-----
> > From: Juergen Schoenwaelder [mailto:[email-masked]]
> > Sent: Friday, September 01, 2000 8:36 AM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]; [email-masked];
> > [email-masked]
> > Subject: Re: sming/sppi/smiv2 integration meeting details
> > 
> > 
> > 
> > >>>>> Keith McCloghrie writes:
> > 
> > Keith> So,
> > 
> > Keith> option b) would be best, if you can resolve it quickly.
> > Keith> option c) would be OK, if it's within driving distance.
> > 
> > I have worked hard on option b) and I finally got very friendly help
> > from T-Nova, the research organization of the Deutsche Telekom. They
> > arranged a meeting room for us in some conference facilities which are
> > located in a castle at the Main river about a hour drive from the
> > Frankfurt airport. So here are the details:
> > 
> >    Tagungshotel Schloss Kleinheubach
> >    Schlosspark 1
> >    63924 Kleinheubach
> >    Germany
> > 
> >    Tel. +49 9371 401-0 
> >    Fax. +49 9371 401 107 
> >    email <[email-masked]>
> > 
> > A very nice photo of the location can be found here:
> > 
> >     <URL:http://www.untermain-online.de/schloss-kleinheubach/>
> > 
> > I have reserved a few rooms in the hotel so that we can actually stay
> > over night in the castle. The rates are very reasonable - about 100 DM
> > which amounts to roughly US $ 50 these days. Please contact the hotel
> > and tell them when you will arrive and how long you are going to
> > stay.
> > 
> > If you experience any problems with the room reservation or you have
> > any other urgent question, you can as well contact Uli Gruen
> > <[email-masked]> from T-Nova who did a great job of organizing
> > this nice meeting place for us.
> > 
> > The web page has a map (under "Anreise") which explains how you reach
> > Kleinheubach from Frankfurt airport by car. The meeting place is
> > directly located at the street B 469. So from the airport, just take
> > highway <3>.  Leave at the exist "Stockstadt" and take the B 469 south
> > until you reach Kleinheubach. The whole trip should not take more than
> > an hour.
> > 
> > You can find all this information including the map and the picture on
> > <URL:http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2000/kl
> > einheubach/>
> > in case the other URL does not work for you.
> > 
> > Sorry that it took so long to get the meeting location finalized. If
> > you are interested, then I can tell you the whole story over a beer or
> > a glass of wine next week.
> > 
> > /js
> > 
> > -- 
> > Juergen Schoenwaelder      Technical University Braunschweig
> > <[email-masked]>  Dept. Operating Systems & Computer Networks
> > Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 
> > Braunschweig, Germany
> > Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>
> > 
> > 
> > 
> 
> 

From: "Durham, David" <[email-masked]>
To: "'Juergen Schoenwaelder'" <[email-masked]>, [email-masked]
Cc: [email-masked], "Durham, David" <[email-masked]>, [email-masked], [email-masked]
Subject: [nmrg] RE: sming/sppi/smiv2 integration meeting details
Date: Fri, 1 Sep 2000 12:17:38 -0700 
Sender: [email-masked]
Status: O
Content-Length: 2815
Lines: 79

Very good. I will be there.
Thanks Juergen,
-Dave

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]]
> Sent: Friday, September 01, 2000 8:36 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: sming/sppi/smiv2 integration meeting details
> 
> 
> 
> >>>>> Keith McCloghrie writes:
> 
> Keith> So,
> 
> Keith> option b) would be best, if you can resolve it quickly.
> Keith> option c) would be OK, if it's within driving distance.
> 
> I have worked hard on option b) and I finally got very friendly help
> from T-Nova, the research organization of the Deutsche Telekom. They
> arranged a meeting room for us in some conference facilities which are
> located in a castle at the Main river about a hour drive from the
> Frankfurt airport. So here are the details:
> 
>    Tagungshotel Schloss Kleinheubach
>    Schlosspark 1
>    63924 Kleinheubach
>    Germany
> 
>    Tel. +49 9371 401-0 
>    Fax. +49 9371 401 107 
>    email <[email-masked]>
> 
> A very nice photo of the location can be found here:
> 
>     <URL:http://www.untermain-online.de/schloss-kleinheubach/>
> 
> I have reserved a few rooms in the hotel so that we can actually stay
> over night in the castle. The rates are very reasonable - about 100 DM
> which amounts to roughly US $ 50 these days. Please contact the hotel
> and tell them when you will arrive and how long you are going to
> stay.
> 
> If you experience any problems with the room reservation or you have
> any other urgent question, you can as well contact Uli Gruen
> <[email-masked]> from T-Nova who did a great job of organizing
> this nice meeting place for us.
> 
> The web page has a map (under "Anreise") which explains how you reach
> Kleinheubach from Frankfurt airport by car. The meeting place is
> directly located at the street B 469. So from the airport, just take
> highway <3>.  Leave at the exist "Stockstadt" and take the B 469 south
> until you reach Kleinheubach. The whole trip should not take more than
> an hour.
> 
> You can find all this information including the map and the picture on
> <URL:http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2000/kl
> einheubach/>
> in case the other URL does not work for you.
> 
> Sorry that it took so long to get the meeting location finalized. If
> you are interested, then I can tell you the whole story over a beer or
> a glass of wine next week.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder      Technical University Braunschweig
> <[email-masked]>  Dept. Operating Systems & Computer Networks
> Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 
> Braunschweig, Germany
> Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>
> 
> 
> 

Date: Fri, 01 Sep 2000 09:04:20 -0700
From: Andy Bierman <[email-masked]>
Organization: Cisco Systems, Inc.
To: Juergen Schoenwaelder <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [nmrg] Re: sming/sppi/smiv2 integration meeting details
Sender: [email-masked]
Status: O
Content-Length: 2898
Lines: 75

Hi Juergen,

> 
> >>>>> Keith McCloghrie writes:
> 
> Keith> So,
> 
> Keith> option b) would be best, if you can resolve it quickly.
> Keith> option c) would be OK, if it's within driving distance.
> 
> I have worked hard on option b) and I finally got very friendly help
> from T-Nova, the research organization of the Deutsche Telekom. They
> arranged a meeting room for us in some conference facilities which are
> located in a castle at the Main river about a hour drive from the
> Frankfurt airport. So here are the details:
> 

I am not going to be able to attend this meeting, but I appreciate
the invitation very much.  As I emphatically stated at the NIM BOF,
I am strongly in favor of this work.  I don't really agree with Keith
that it is independent of the NIM effort, but I do agree that
this work is long overdue, and a WG should be formed ASAP.
(Maybe that's what Keith meant :-) 

Maybe I could attend the next meeting, hopefully a WG meeting
at IETF #49 in San Diego.

Andy

>    Tagungshotel Schloss Kleinheubach
>    Schlosspark 1
>    63924 Kleinheubach
>    Germany
> 
>    Tel. +49 9371 401-0
>    Fax. +49 9371 401 107
>    email <[email-masked]>
> 
> A very nice photo of the location can be found here:
> 
>     <URL:http://www.untermain-online.de/schloss-kleinheubach/>
> 
> I have reserved a few rooms in the hotel so that we can actually stay
> over night in the castle. The rates are very reasonable - about 100 DM
> which amounts to roughly US $ 50 these days. Please contact the hotel
> and tell them when you will arrive and how long you are going to
> stay.
> 
> If you experience any problems with the room reservation or you have
> any other urgent question, you can as well contact Uli Gruen
> <[email-masked]> from T-Nova who did a great job of organizing
> this nice meeting place for us.
> 
> The web page has a map (under "Anreise") which explains how you reach
> Kleinheubach from Frankfurt airport by car. The meeting place is
> directly located at the street B 469. So from the airport, just take
> highway <3>.  Leave at the exist "Stockstadt" and take the B 469 south
> until you reach Kleinheubach. The whole trip should not take more than
> an hour.
> 
> You can find all this information including the map and the picture on
> <URL:http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2000/kleinheubach/>
> in case the other URL does not work for you.
> 
> Sorry that it took so long to get the meeting location finalized. If
> you are interested, then I can tell you the whole story over a beer or
> a glass of wine next week.
> 
> /js
> 
> --
> Juergen Schoenwaelder      Technical University Braunschweig
> <[email-masked]>  Dept. Operating Systems & Computer Networks
> Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
> Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

Date: Fri, 1 Sep 2000 17:35:55 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [nmrg] Re: sming/sppi/smiv2 integration meeting details
Sender: [email-masked]
Status: O
Content-Length: 2311
Lines: 62

>>>>> Keith McCloghrie writes:

Keith> So,

Keith> option b) would be best, if you can resolve it quickly.
Keith> option c) would be OK, if it's within driving distance.

I have worked hard on option b) and I finally got very friendly help
from T-Nova, the research organization of the Deutsche Telekom. They
arranged a meeting room for us in some conference facilities which are
located in a castle at the Main river about a hour drive from the
Frankfurt airport. So here are the details:

   Tagungshotel Schloss Kleinheubach
   Schlosspark 1
   63924 Kleinheubach
   Germany

   Tel. +49 9371 401-0 
   Fax. +49 9371 401 107 
   email <[email-masked]>

A very nice photo of the location can be found here:

    <URL:http://www.untermain-online.de/schloss-kleinheubach/>

I have reserved a few rooms in the hotel so that we can actually stay
over night in the castle. The rates are very reasonable - about 100 DM
which amounts to roughly US $ 50 these days. Please contact the hotel
and tell them when you will arrive and how long you are going to
stay.

If you experience any problems with the room reservation or you have
any other urgent question, you can as well contact Uli Gruen
<[email-masked]> from T-Nova who did a great job of organizing
this nice meeting place for us.

The web page has a map (under "Anreise") which explains how you reach
Kleinheubach from Frankfurt airport by car. The meeting place is
directly located at the street B 469. So from the airport, just take
highway <3>.  Leave at the exist "Stockstadt" and take the B 469 south
until you reach Kleinheubach. The whole trip should not take more than
an hour.

You can find all this information including the map and the picture on
<URL:http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2000/kleinheubach/>
in case the other URL does not work for you.

Sorry that it took so long to get the meeting location finalized. If
you are interested, then I can tell you the whole story over a beer or
a glass of wine next week.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>