Subject: [nmrg] welcome on the NMRG mailing list
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Cc: Network Management Research Group <[email-masked]>
Date: Thu, 29 Jul 1999 13:19:44 +0200

I have added you to the NMRG mailing list since you are soon our
official IRTF chair. Welcome aboard.
							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)

Date: Mon, 26 Jul 1999 16:25:54 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] compression in SNMPv1
Sender: [email-masked]

>>>>> Aiko Pras writes:

Aiko> This is exactly what I wanted to say. We can save on the number
Aiko> of round-trip delays (our goal) by packing the data into fewer
Aiko> responses (the mechanism to achieve the goal).

Aiko> The point I wanted to make is that a see compression primarily
Aiko> useful for reducing the number of round-trip
Aiko> delays. Particularly with Get-Next and Get-Bulk we can gain a
Aiko> lot; with Get-Tree we will not gain as much since we have at
Aiko> SNMP level only a single request which results into multiple
Aiko> responses. Therefore Get-Tree requires a smaller number of
Aiko> round-trips.  YES, I do agree that compression is also useful to
Aiko> save on bandwidth.  Unfortunately, this doesn't come for free:
Aiko> we have to introduce extra complexity at the two end systems
Aiko> (the manager and agent). However, since the growth in bandwidth
Aiko> is MUCH (!!!) higher than the growth in CPU power and memory
Aiko> speed, we should be reluctant to further complicate the end
Aiko> systems. We shouldn't make the classical mistake to justify
Aiko> design decisions for the future on the bandwidth / CPU ratio of
Aiko> today!  In my opinion the savings on bandwidth do not
Aiko> sufficiently justify the additional complexity of compression;
Aiko> the gain on delay however does justify compression.

I think it really depends on your environment. Compression as we
discussed it so far is indeed an optional feature and people who are
living in an environment where it makes sense to use compression can
enable this feature. The complexity of compression is really small
implementationwise. However, the runtime impact can be significant
(both, in terms of CPU usage as well as bandwidth savings ;-). Note
that it does not cost anything if you choose to ignore compression.

Aiko> I agree that the receiver can detect from the incoming data that
Aiko> it must be compressed. However, I assume that the same is true
Aiko> for encryption (the receiver can detect from the incoming data
Aiko> that the data is encrypted). Why is it that there is still a
Aiko> flag for privacy?

SNMPv3 does not ship encrypted data in its own PDU type. Hence they
need a bit which tells the receiver that the payload is encrypted.

							Juergen

Date: Mon, 26 Jul 1999 15:50:43 +0200
From: Aiko Pras <[email-masked]>
To: Juergen Schoenwaelder <[email-masked]>, Jean-Philippe Martin-Flatin <[email-masked]>
CC: [email-masked]
Subject: Re: [nmrg] compression in SNMPv1
Sender: [email-masked]

Hi

>From the reactions of Juergen and Jean-Philippe I must conclude that I
failed to formulate my ideas well.

> Aiko> 1) Our main goal is probably not saving on the number of bits
> Aiko> that need to be transported, but saving on the number of
> Aiko> round-trips (= time) that are currently needed (since we only
> Aiko> have GetNext and GetBulk) to fetch large amounts of data.
>Juergen> You are missing the fact that compression allows to put much
>Juergen> more data into a response. This can drastically reduce the 
>Juergen> number of round-trips you need with GetBulk (and GetTree).
This is exactly what I wanted to say. We can save on the number of
round-trip delays (our goal) by packing the data into fewer responses 
(the mechanism to achieve the goal).

The point I wanted to make is that a see compression primarily useful
for reducing the number of round-trip delays. Particularly with Get-Next
and Get-Bulk we can gain a lot; with Get-Tree we will not gain as much
since we have at SNMP level only a single request which results into
multiple responses. Therefore Get-Tree requires a smaller number of
round-trips.
YES, I do agree that compression is also useful to save on bandwidth.
Unfortunately, this doesn't come for free: we have to introduce extra
complexity at the two end systems (the manager and agent). However,
since the growth in bandwidth is MUCH (!!!) higher than the growth in
CPU power and memory speed, we should be reluctant to further
complicate  the end systems. We shouldn't make the classical mistake to
justify design decisions for the future on the bandwidth / CPU ratio of
today!
In my opinion the savings on bandwidth do not sufficiently justify the
additional complexity of compression; the gain on delay however does
justify compression. 

> Aiko> 5) With respect to SNMPv3, the most promising approach I see now
> Aiko> is using two of the message flags.
>Juergen> Make that 1 message flag and the CompressedPDU and I agree.
I agree that the receiver can detect from the incoming data that it must
be compressed. However, I assume that the same is true for encryption
(the receiver can detect from the incoming data that the data is
encrypted). Why is it that there is still a flag for privacy?

> Aiko> 6) In that case I propose we choose ONE compression algorithm
> Aiko> for ever.
>JP> I'm strongly opposed to that. Even the Java folks, who like to
>JP> casteverything in Java iron, supported 2 compression schemes
>JP> from day 1: gzip (to please the Unix world) and zip (to please 
>JP> the Windows world). Tomorrow, a Unisys-like patent issue might 
>JP> cause contempt for the compression algorithm you selected 
>JP> "forever". We don't want to be exposed to such design problems.
OK, You're right. I guess I over-simplified things

Bye

Aiko

Date: Mon, 26 Jul 1999 14:51:34 +0200
From: Aiko Pras <[email-masked]>
To: "[email-masked]" <[email-masked]>
CC: TSS management group <[email-masked]>
Subject: [nmrg] Another SNMP over TCP implementation available
Sender: [email-masked]

Hi all

Based on the UCD SNMP package version 3.6.2, also the UT has made an
experimental implementation of SNMP over TCP.

Everyone can test the agent, which runs on port 8081 on the
heisenberg.cs.utwente.nl. The community string is public. If the agent
does not respond, please send an email and we will restart the agent.

Not only the agent, but also the manager role has been implemented and
tested (on solaris, linux, and Windows-NT (apart from the agent)). If
you want to get the code, please let us know.

Bye

Aiko

Date: Fri, 23 Jul 1999 09:12:16 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] compression in SNMPv1
Sender: [email-masked]

>>>>> J P Martin-Flatin writes:

JP> I'm glad to read that Juergen now wants 3 different RFCs for these
JP> 3 features; he wanted just one a few weeks ago, which I wasn't
JP> happy with.

I probably did not express myself very well: I always had in mind to
work out three independent specifications. What I was talking about in
Boston is that I have a strong preference to publish all three
documents together as a single deliverable of the NMRG.

							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)

Date: Thu, 22 Jul 1999 23:33:04 +0200
From: Ron Sprenkels <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [nmrg] compression in SNMPv1
Sender: [email-masked]

Hi Folks,

> > 1) Our main goal is probably not saving on the number of bits that
> >    need to be transported, but saving on the number of round-trips
> >    (= time) that are currently needed (since we only have GetNext
> >    and GetBulk) to fetch large amounts of data.
> 
> I disagree. The overall goal is to keep both the latency and the
> network overhead low. 

I agree that those are two goals we want to achieve. If we would want to
rank the two, I'd say the most important one is to get latency down, and
then to reduce the number of bytes sent over the wire. My reason for this
is that right here and now, If I retrieve a lot of MIB data with get-nexts,
in one thread (so in order), it is in my LAN case not the lack of bandwidth
that is slowing things down, but the number of round trip times I need. But
yes, we want to address _both_ issues.

> By compressing data, you decrease the number
> of messages (-> less overhead at the end hosts and at the routers)
> and you increase the payload-to-header ratio ("more buck to the byte").

This is true IFF the implementation manages to fill up the messages close
to maxmessagesize. If an implementation choses to fill up a message (close)
to maxmessagesize, and then compresses it and sends it over the wire, you
just save bytes over the wire, but the number of messages (and needed rtts)
stays the same. So I guess we should/SHOULD explicitly encourage
implementers to fill up those messages to the limit.

> Everybody expects the amount of management data to move about to
> increase in tomorrow's networks, and no network administrator wants
> to tell his boss that the proportion of the link capacity used up by
> management overhead is increasing. 

That indeed does sound as harmful to the guy's carreer :-)

> The best solution to satisfy these
> two opposite constraints is compression.

Compression, if done right, improves latency (by reducing # rtts) and
reduces # bytes sent over the wire. Also the latter goal can be missed,
when e.g. gzipping single short varbind requests/responses. In that case,
they get bigger! So like always, some common sense must be applied to the
whole process.
 
> > 2) If we have a GetTree over TCP, we need only one round trip to fetch
> >    the complete MIB! In that case, compression doesn't save much time.
 
> This is wrong, as Juergen pointed out. With an 8K message size, most
> tables will require several TCP messages. Even with 64K, many tables
> wouldn't fit in a single message.

I believe that in common cases putting GetSubtree over TCP _could_ move the
bottleneck from the system from rtt-bound to bandwidth-bound. Rtt in the
getsubtree over tcp scenario is only the bottleneck iff the agent manages
to send linked responses at such a high rate that it has to wait for the
manager's side TCP stack to ack the reception of n-times ago sent chunck of
data. In other words, if the TCP protocol runs out of its windowsize. Now,
I am not really sure here, but as far as I know, this occurs only in very
high rtt-latencey-times-bandwidth cases.
 
> > 3) Intermediate conclusion: compression can be a useful, but not an
> >    essential feature (I consider TCP and GetTree more important).
> 
> I don't want to rank them, because their usefulness is site specific.
> There are really independent. I'm glad to read that Juergen now wants
> 3 different RFCs for these 3 features; he wanted just one a few weeks
> ago, which I wasn't happy with.

Getting them in some order of importance is difficult, if not impossible.
And as JP says, depends on the situation at hand. So looking at them
independantly is probably best. On LANs I could imagine that compression is
not as important as reducing the number of individual chuncks of data to be
processed. In a wireless/WAN environment raw bandwidth might be the most
precious thing, so you would want compression first. So it depends.
 
> > 6) In that case I propose we choose ONE compression algorithm for ever.
> 
> I'm strongly opposed to that. Even the Java folks, who like to cast
> everything in Java iron, supported 2 compression schemes from day 1:
> gzip (to please the Unix world) and zip (to please the Windows world).

I'll go along with this motivation a long way. One mechanism that probably
_reduces_ the number of algorithms you want is have the mechanism where
things are compressed only if the result is actually smaller than the
original. So try, and if bigger, forget it. If you have that, the need for
different algorithms, depending on if you are going to compress alot or
just a single varbind, goes away a bit. I am not sure if it would be
reduced to just a single algorithm.

> Tomorrow, a Unisys-like patent issue might cause contempt for the
> compression algorithm you selected "forever". We don't want to be
> exposed to such design problems.

Now this would be a bad thing. Which makes a good reason to support
different algorithms. If possible.

Ron.

From: "J.P. Martin-Flatin" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: [nmrg] compression in SNMPv1 
Date: Thu, 22 Jul 1999 18:53:13 +0200
Sender: [email-masked]

Hi,

On Wed, 21 Jul 1999 10:30:47 +0200, Aiko Pras wrote:
> 
> 1) Our main goal is probably not saving on the number of bits that
>    need to be transported, but saving on the number of round-trips
>    (= time) that are currently needed (since we only have GetNext
>    and GetBulk) to fetch large amounts of data.

I disagree. The overall goal is to keep both the latency and the
network overhead low. By compressing data, you decrease the number
of messages (-> less overhead at the end hosts and at the routers)
and you increase the payload-to-header ratio ("more buck to the byte").
Everybody expects the amount of management data to move about to
increase in tomorrow's networks, and no network administrator wants
to tell his boss that the proportion of the link capacity used up by
management overhead is increasing. The best solution to satisfy these
two opposite constraints is compression.

> 2) If we have a GetTree over TCP, we need only one round trip to fetch
>    the complete MIB! In that case, compression doesn't save much time.

This is wrong, as Juergen pointed out. With an 8K message size, most
tables will require several TCP messages. Even with 64K, many tables
wouldn't fit in a single message.

> 3) Intermediate conclusion: compression can be a useful, but not an  
>    essential feature (I consider TCP and GetTree more important).

I don't want to rank them, because their usefulness is site specific.
There are really independent. I'm glad to read that Juergen now wants
3 different RFCs for these 3 features; he wanted just one a few weeks
ago, which I wasn't happy with.

> 6) In that case I propose we choose ONE compression algorithm for ever.

I'm strongly opposed to that. Even the Java folks, who like to cast
everything in Java iron, supported 2 compression schemes from day 1:
gzip (to please the Unix world) and zip (to please the Windows world).
Tomorrow, a Unisys-like patent issue might cause contempt for the
compression algorithm you selected "forever". We don't want to be
exposed to such design problems.

Jean-Philippe

____________________________________________________________________
Jean-Philippe Martin-Flatin, EPFL-DI-ICA, 1015 Lausanne, Switzerland
Email: [email-masked]                   Fax: +41-21-693-66-10
Web: http://icawww.epfl.ch/~jpmf/

Date: Wed, 21 Jul 1999 10:55:24 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] compression in SNMPv1
Sender: [email-masked]

>>>>> Aiko Pras writes:

Aiko> Probably we need two flags: one indicating that the current
Aiko> message / PDU is compressed, and to other indicating that the
Aiko> response should (preferably) be compressed. After that we still
Aiko> have three flag bits left ...

The first bit is not needed since we have to introduce a compressed
PDU anyway in order to express things well in ASN.1. Hence you get the
bit from the PDU tag.

Aiko> After thinking a while over the issue, I've currently the
Aiko> following feelings:

Aiko> 1) Our main goal is probably not saving on the number of bits
Aiko> that need to be transported, but saving on the number of
Aiko> round-trips (= time) that are currently needed (since we only
Aiko> have GetNext and GetBulk) to fetch large amounts of data.

You are missing the fact that compression allows to put much more data
into a response. This can drastically reduce the number of round-trips
you need with GetBulk (and GetTree).

Aiko> 2) If we have a GetTree over TCP, we need only one round trip to
Aiko> fetch the complete MIB! In that case, compression doesn't save
Aiko> much time.

You are missing the fact that even with GetTree, we end up having
multiple response due to buffer size constraints. Furthermore,
reducing the overall size of the response(s) will result in fewer
round trips in the TCP layer.

Aiko> 3) Intermediate conclusion: compression can be a useful, but not
Aiko> an essential feature (I consider TCP and GetTree more
Aiko> important).

I agree as long as the data sizes are sufficiently small. If I take
your accounting data example, then compression may make a big
difference. Of course, this depends on the available bandwidth, the
CPU power you have and so on.

Aiko> 4) Therefore it would be unwise to come up with a solution for
Aiko> compression that would violate SNMPs architecture too much.
Aiko> SNMPv3 is already difficult to understand (because the problem
Aiko> it is solving is difficult), and making it more complex to
Aiko> introduce a useful, but not essential feature may not be a good
Aiko> idea.

I generally agree that we should not violate the architecture. You are
right that compression is a feature. And that is why we put the three
things (SNMP over TCP, Compression, GetTree) into seperate specs that
can be implemented and used independently.

Aiko> 5) With respect to SNMPv3, the most promising approach I see now
Aiko> is using two of the message flags.

Make that 1 message flag and the CompressedPDU and I agree.

Aiko> 6) In that case I propose we choose ONE compression algorithm
Aiko> for ever.  My motivation is one of "architectural symmetry"
Aiko> (isn't that a nice term?). Let me explain. The message flags are
Aiko> currently used for authentication & encryption (plus report
Aiko> generation). The choice which authetication / encryption
Aiko> algorithms to use, is determined by the msgsecuritymodel
Aiko> parameter, immediately after the msgflags field. For the purpose
Aiko> of choosing between different compression algorithms we can not
Aiko> introduce a new field 'msgcompressionmodel'.  Therefore I
Aiko> suggest to choose a single compression algorithm.

I disagree. What we learned in Oslo is that compression algorithms
really behave quite different and I have doubts that its possible to
find a one-size-fits-all algorithm. Furthermore, your analogy
wrt. authentication and encryption algorithms in SNMPv3 is wrong. The
msgSecurityModel only identifies the security model (e.g. USM).
Within the USM security model, you identify the algorithm to be used
by looking into the usmUserTable, which is bound to the msgUserName of
the UsmSecurityParameters. If we bind the compression algorithm to the
engineID, then we do not need to introduce any new fields in the
message header. And we are basically doing the same trick that USM
is already using.
							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)

Date: Wed, 21 Jul 1999 10:30:47 +0200
From: Aiko Pras <[email-masked]>
To: [email-masked]
CC: Juergen Schoenwaelder <[email-masked]>, [email-masked]
Subject: Re: [nmrg] compression in SNMPv1
Sender: [email-masked]

Hi all

> Dave> Just to add another possibility to the list...
> Dave> [skip]
> 
Juergen> I think the issue was to find a bit which could be allocated so that
Juergen> a) an agent supporting compression can apply compression at its own
Juergen> discretion and b) an existing agent not supporting compression will
Juergen> process the message as usual. This is possible in SNMPv3 by allocating
Juergen> one of the unused msgFlags.
Probably we need two flags: one indicating that the current message / PDU
is compressed, and to other indicating that the response should 
(preferably) be compressed. After that we still have three flag bits 
left ...

After thinking a while over the issue, I've currently the following feelings:
1) Our main goal is probably not saving on the number of bits that need to
   be transported, but saving on the number of round-trips (= time) that 
   are currently needed (since we only have GetNext and GetBulk) to
   fetch large amounts of data.
2) If we have a GetTree over TCP, we need only one round trip to fetch
   the complete MIB! In that case, compression doesn't save much time.
3) Intermediate conclusion: compression can be a useful, but not an  
   essential feature (I consider TCP and GetTree more important).
4) Therefore it would be unwise to come up with a solution for compression
   that would violate SNMPs architecture too much. SNMPv3 is already 
   difficult to understand (because the problem it is solving is difficult),
   and making it more complex to introduce a useful, but not essential 
   feature may not be a good idea.
5) With respect to SNMPv3, the most promising approach I see now is using
   two of the message flags.
6) In that case I propose we choose ONE compression algorithm for ever.
   My motivation is one of "architectural symmetry" (isn't that a nice
   term?). Let me explain. The message flags are currently used for
   authentication & encryption (plus report generation). The choice
   which authetication / encryption algorithms to use, is determined
   by the msgsecuritymodel parameter, immediately after the msgflags
   field. For the purpose of choosing between different compression 
   algorithms we can not introduce a new field 'msgcompressionmodel'.
   Therefore I suggest to choose a single compression algorithm.

> I more or less came to the conclusion that
> this is not possible in SNMPv1/SNMPv2c. All the solutions discussed so
> far (including the new port number proposal) fail to support a) and b)
> wrt. SNMPv1/SNMPv2c.
In SNMPv1/SNMPv2c it is possible to introduce a separate varbind
to indicate that the response should be compressed. While this has
the nice feature that would be transparent to existing 
SNMPv1/SNMPv2c implementations (they behave exactly as expected),
it is not architectural clean. Given the reasoning above, we should
probably not take this solution.

Bye

Aiko

Date: Tue, 20 Jul 1999 09:57:23 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] compression in SNMPv1
Sender: [email-masked]

>>>>> Dave Thaler writes:

Dave> Just to add another possibility to the list...

Dave> The context of this email is the discussion last Thursday of how
Dave> a manager could specify in SNMPv1 that a compressed response
Dave> would be preferred (with the assumption that only one
Dave> compression type is supported for SNMPv1), and you need to find
Dave> a bit somewhere.

Dave> An alternative that hasn't been mentioned yet is to allow the
Dave> agent to listen on a separate well-known port number.  A request
Dave> on 161 is then always normal (no compression), and a request
Dave> sent to another well-known port means compression is requested.

I think the issue was to find a bit which could be allocated so that
a) an agent supporting compression can apply compression at its own
discretion and b) an existing agent not supporting compression will
process the message as usual. This is possible in SNMPv3 by allocating
one of the unused msgFlags. I more or less came to the conclusion that
this is not possible in SNMPv1/SNMPv2c. All the solutions discussed so
far (including the new port number proposal) fail to support a) and b)
wrt. SNMPv1/SNMPv2c.

My conclusion therefore is the following: In SNMPv1/SNMPv2c, the
receiving SNMP engine is only allowed to do compression when it
received a compressed request. This means that uncompressed requests
leading to compressed responses are only possible in SNMPv3, while
SNMPv1/SNMPv2c only support compressed requests leading to compressed
responses. I think this is a fair and clean solution (and it gives
some motivation to move to SNMPv3).
							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)

From: Dave Thaler <[email-masked]>
Subject: [nmrg] compression in SNMPv1
To: [email-masked]
Date: Mon, 19 Jul 1999 18:07:16 -0700 (PDT)
Sender: [email-masked]

Just to add another possibility to the list...

The context of this email is the discussion last Thursday of how a 
manager could specify in SNMPv1 that a compressed response would be 
preferred (with the assumption that only one compression type is 
supported for SNMPv1), and you need to find a bit somewhere.

An alternative that hasn't been mentioned yet is to allow the agent
to listen on a separate well-known port number.  A request on 161 is
then always normal (no compression), and a request sent to another
well-known port means compression is requested.

-Dave

From: Dave Thaler <[email-masked]>
Subject: [nmrg] GET-SUBTREE-MIB
To: [email-masked]
Date: Mon, 19 Jul 1999 18:01:02 -0700 (PDT)
Sender: [email-masked]

I brought this up on Sunday, and we decided that it needed more 
thought/discussion, so to generate some discussion, here's
a strawman MIB which would allow get-subtree operations without 
changing SNMP.

(Discussion continued after the mib, below...)

GET-SUBTREE-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
    Unsigned32, Counter32             FROM SNMPv2-SMI
    RowStatus, TruthValue             FROM SNMPv2-TC
    MODULE-COMPLIANCE, OBJECT-GROUP,
    NOTIFICATION-GROUP                FROM SNMPv2-CONF
    SnmpAdminString                   FROM SNMP-FRAMEWORK-MIB;

getSubtreeMIB MODULE-IDENTITY
    LAST-UPDATED "9907161200Z"
    ORGANIZATION "IRTF Network Management Research Group"
    CONTACT-INFO
            " Dave Thaler
              Microsoft Corporation
              One Microsoft Way
              Redmond, WA  98052-6399
              EMail: [email-masked]"
    DESCRIPTION
            "This MIB module provides the ability to retrieve an arbitary
            subtree of OIDs by receiving traps."
    ::= { XXX } 

getSubtreeMIBObjects OBJECT IDENTIFIER ::= { getSubtreeMIB 1 }

getSubtree           OBJECT IDENTIFIER ::= { getSubtreeMIBObjects 1 }
getSubtreeTraps      OBJECT IDENTIFIER ::= { getSubtreeMIBObjects 2 }

getSubtreeTable OBJECT-TYPE
    SYNTAX     SEQUENCE OF GetSubtreeEntry
    MAX-ACCESS not-accessible
    STATUS     current
    DESCRIPTION
            "The (conceptual) table containing information on 
            GET-SUBTREE operations in progress."
    ::= { getSubtree 1 }

getSubtreeEntry OBJECT-TYPE
    SYNTAX     GetSubtreeEntry
    MAX-ACCESS not-accessible
    STATUS     current
    DESCRIPTION
            "An entry (conceptual row) containing the information on a
            particular GET-SUBTREE operation in progress."
    INDEX      { getSubtreeIndex }
    ::= { getSubtreeTable 1 }

GetSubtreeEntry ::= SEQUENCE {
    getSubtreeIndex            Unsigned32,
    getSubtreeTargetAddrName   SnmpAdminString,
    getSubtreeRootOid          OBJECT IDENTIFIER,
    getSubtreeSequenceNumber   Counter32,
    getSubtreeDone             TruthValue,
    getSubtreeStatus           RowStatus
}

getSubtreeIndex OBJECT-TYPE
    SYNTAX     Unsigned32
    MAX-ACCESS not-accessible
    STATUS     current
    DESCRIPTION
            "An integer uniquely identifying the GET-SUBTREE operation in 
            progress.  This value should be randomly generated by a
            manager before attempting to create the row."
    ::= { getSubtreeEntry 1 }

getSubtreeTargetAddrName OBJECT-TYPE
    SYNTAX     SnmpAdminString
    MAX-ACCESS read-create
    STATUS     current
    DESCRIPTION
            "This object selects a management target defined in the
            snmpTargetAddrTable (in the SNMP-TARGET-MIB).  The
            selected target is defined by an entry in the
            snmpTargetAddrTable whose index value (snmpTargetAddrName)
            is equal to this object."
    ::= { getSubtreeEntry 2 }

getSubtreeRootOid OBJECT-TYPE
    SYNTAX     OBJECT IDENTIFIER
    MAX-ACCESS read-create
    STATUS     current
    DESCRIPTION
            "The OID of the subtree to be sent."
    ::= { getSubtreeEntry 3 }

getSubtreeSequenceNumber OBJECT-TYPE
    SYNTAX     Counter32
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
            "The number of trap responses previously sent for this request."
    ::= { getSubtreeEntry 4 }

getSubtreeDone OBJECT-TYPE
    SYNTAX     TruthValue
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
            "This is set to true in the last trap sent, and is set to 
            false otherwise."
    ::= { getSubtreeEntry 5 }

getSubtreeStatus OBJECT-TYPE
    SYNTAX     RowStatus
    MAX-ACCESS read-create
    STATUS     current
    DESCRIPTION
            "The status of this row, by which new entries may be
            created, or old entries deleted from this table.  Once
            created, the row may be deleted, but other objects in the
            row may not be modified.  A row will be deleted automatically
            by the agent once the operation has completed."
    ::= { getSubtreeEntry 6 }

-- traps

getSubtreeTrapPrefix OBJECT IDENTIFIER ::= { getSubtreeTraps 0 }

getSubtreeResponse NOTIFICATION-TYPE
    OBJECTS { getSubtreeSequenceNumber, getSubtreeDone }
    STATUS current
    DESCRIPTION
           "In addition to the two objects above, this trap also 
           contains a series of varbinds containing the next chunk of 
           the subtree.  The generating entity will append, in order, 
           as many variables to the variable-bindings field as it can 
           without exceeding the maximum message size, and without going 
           beyond the subtree of OIDs requested.  A series of such
           traps will be generated until the end of the subtree is 
           reached."
    ::= { getSubtreeTrapPrefix 1 }

-- conformance information

getSubtreeMIBConformance 
                  OBJECT IDENTIFIER ::= { getSubtreeMIB 2 }
getSubtreeMIBCompliances
                  OBJECT IDENTIFIER ::= { getSubtreeMIBConformance 1 }
getSubtreeMIBGroups  OBJECT IDENTIFIER ::= { getSubtreeMIBConformance 2 }

-- compliance statements

getSubtreeMIBCompliance MODULE-COMPLIANCE
    STATUS  current
    DESCRIPTION
            "The compliance statement for the GetSubtree MIB."
    MODULE  -- this module
    MANDATORY-GROUPS { getSubtreeObjectGroup, 
                       getSubtreeNotificationGroup }
   ::= { getSubtreeMIBCompliances 1 }

-- units of conformance

getSubtreeObjectGroup OBJECT-GROUP
    OBJECTS { getSubtreeTargetAddrName, getSubtreeRootOid, 
              getSubtreeSequenceNumber, getSubtreeDone,
              getSubtreeStatus }
    STATUS  current
    DESCRIPTION
            "A collection of objects to support requests for
            subtree retrieval operations."
    ::= { getSubtreeMIBGroups 1 }

getSubtreeNotificationGroup NOTIFICATION-GROUP
    NOTIFICATIONS { getSubtreeResponse }
    STATUS  current
    DESCRIPTION
           "The notification which an entity is required to implement."
    ::= { getSubtreeMIBGroups 2 }

END

As discussed last week, the interesting issue is how to get
the information back to the application that issued the "request".
As you will see above, I tentatively put in an SnmpAdminString object 
which provides an index into the SNMP-TARGET-MIB.

HOWEVER, it would be nice to be able to initiate a get-subtree
with a single SET from an arbitrary application.  Another
(perhaps more desirable) possibility would be to either add a 
columnar TAddress object that would also create a temporary row 
in the SNMP-TARGET-MIB, or perhaps it could be created automatically 
based on the source address/port of the SET?  It's interesting to note
that this would make it possible to have the traps sent back to a port
other than 162, such as the port the app sends the SET from, so
that the response to the SET, and the traps, all go back to the same port.

-Dave

Date: Fri, 16 Jul 1999 10:58:15 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: [nmrg] first Oslo meeting results
Sender: [email-masked]

>>>>> Wes Hardaker writes:

Wes> The one thing that I think would be necessary would be to
Wes> indicate the compression algorithm in the message sent, rather
Wes> than by a previous "set" or "configuration" or "default" of the
Wes> engine you're talking to.  That will cause problems with multiple
Wes> entities talking to the same engine and they each want to use a
Wes> different compression function.

Yes. We had some discussion about this and other issues yesterday once
we had the first prototype running. I hope to be able to send out an
updated version of the proposal when I am back home.

Wes> How about a table of supported compressions and then have the
Wes> compression type indicated in the beginning of the octet string?
Wes> Most compression algorithms (I think) have a magic X number of
Wes> bytes in the beginning of the string don't they?

The question is whether you want to rely on these bytes (which are not
under central control). Anyway, I believe that there will be few
compression algorithms in practice and I also expect that you will not
change compressions algorithms regularily. So the question is whether
it really makes sense to indicate the algorithm in every message. BTW,
you do not find an indication of the encryption or authentication
algorithm in SNMPv3 either.

Wes> Though, I'll leave the CompressionType definition up to future
Wes> debate...  An OID is too long, but anything else would be more of
Wes> a registration pain.

Yes. And hence a MIB object might be a cheap way out. A manager can
retrieve this object before starting a bulk retrieval. This also has
the advantage that the manager knows whether the agent supports
compression at all. And in the notification originator case, you need
to have local configuration information in order to determine whether
you can use compression.
							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)

To: Juergen Schoenwaelder <[email-masked]>
Cc: Network Management Research Group <[email-masked]>, [email-masked]
Subject: Re: [nmrg] first Oslo meeting results
Organization: U.C.Davis, Information Technology - D.C.A.S.
From: Wes Hardaker <[email-masked]>
Date: 15 Jul 1999 10:33:51 -0700
Lines: 68
Sender: [email-masked]

>>>>> On Mon, 12 Jul 1999 14:40:25 +0200, Juergen Schoenwaelder <[email-masked]> said:

Juergen> Below is some stuff I wrote down this morning.

I'll try for a longer response next week, when I have more time, but...

Juergen> NMRG-SNMP-COMPRESSED-PDU DEFINITIONS ::= BEGIN

Juergen> CompressedPDU ::= 		    -- contains a compressed PDU
Juergen> [9] IMPLICIT
Juergen> OCTET STRING

Juergen> END

...

Juergen> o I propose to bind the compression algorithm to the SNMP engine
Juergen> rather than a securityName within an SNMP engine.

Agreed, though...

Juergen> snmpEngineCompProtocol OBJECT-TYPE
Juergen>       SYNTAX	AutonomousType
Juergen>       MAX-ACCESS	read-write
Juergen>       STATUS	current
Juergen>       DESCRIPTION
Juergen>         "The compression protocol used by the SNMP engine. The value
Juergen>         zeroDotZero indicates that the SNMP engine does not support
Juergen>         SNMP compression. The value of this object may be changed
Juergen>         to select a different compression protocol. Attempts to set
Juergen>         this object to a compression algorithm not supported by the
Juergen>         SNMP engine will result in an inconsistentValue error."
Juergen>       DEFVAL	{ zeroDotZero }
Juergen>       ::= { snmpCompObjects 1 }

The one thing that I think would be necessary would be to indicate the 
compression algorithm in the message sent, rather than by a previous
"set" or "configuration" or "default" of the engine you're talking
to.  That will cause problems with multiple entities talking to the
same engine and they each want to use a different compression
function.

How about a table of supported compressions and then have the
compression type indicated in the beginning of the octet string?  Most 
compression algorithms (I think) have a magic X number of bytes in the 
beginning of the string don't they?  Or, actually have the
CompressedPDU be more like:

  CompressedPDU ::= 		    -- contains a compressed PDU
   [9]
       IMPLICIT SEQUENCE {
           compression-type
               CompressionType,
  
           compressed-pdu
               OCTET STRING
       }
  
  END

Though, I'll leave the CompressionType definition up to future
debate...  An OID is too long, but anything else would be more of a
registration pain.

-- 
Wes Hardaker
Distributed Computing Analysis and Support
University of California at Davis

Date: Wed, 14 Jul 1999 18:26:20 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] Conserving memory
Sender: [email-masked]

>>>>> J P Martin-Flatin writes:

JP> I find our discussion about buffer sizes slightly
JP> anachronistic. People in the JINI world are now taking for granted
JP> that we have a JVM and a significant amount of software embedded
JP> in all the devices that we find in our day-to-day life: that's
JP> what it takes to implement a universal plug and play (automatic
JP> configuration) that isn't bound to Windows and that doesn't cost
JP> as much as CORBA. Many device vendors have signed in the JINI
JP> concept. The memory requirements of such a scenario render our
JP> discussion obsolete.

Lets talk about this when we are a few years older. Perhaps it turns
out that vendors signing in into JINI was the anachronistic action. ;-)

							Juergen

Date: Wed, 14 Jul 1999 15:38:14 +0200
From: [email-masked] (Bert-Jan van Beijnum)
To: [email-masked]
Sender: [email-masked]

Oslo Minutes (11 July, 1999)
============================

Present:
Juergen Schoenwalder (JS), University of Braunscheig
Aiko Pras (AP), University of Twente
Ron Sprenkel (RS) University of Twente
Bert Wijnen (BW) IBM
Bert-Jan van Beijnum (BJ) University of Twente
Eric Schoenfelder(E)
Dave Thaler (D) Microsoft

Agenda:
=======
1. discuss any open issues w.r.t. the SNMP over TCP document
2. discuss and select an approach for SNMP payload compression
3. work out the details of the GetSubTree protocol operation
4. (if time is left) discuss the SMIng specification
5. discuss other topics such as meta-level discussions on NMRG.

We started the meeting outside: the wether was nice and the door was 
closed so we couldn’t get in.

1 SNMP over TCP document
========================
*About closing TCP connection: what when connections gets lost/closes?

option1: do not specify.
motivation: it aligns with the UDP case

option2:do specify. TCP i.e. a request is send and agent received it.
motivtion: with UDP: you dont’n know of a request arrives, with tcp you 
do know.

Discussion
----------

example: if you do a bulkset, you want to know wether it succeeded 
(arrival is nice, but you don’t know if it succeeded when the tcp 
connection is broken).
observation: you could do either a confirmed or an unconfirmed set-
opeeration.

After we went in, Bert-Jan made some coffee, which we all appreciated!

The fundamental issue is: what are the consequences for the application.

traps & inform: transport gets confirmed.
with sets: confirms tell you that they have been transported and 
processed. 

BW: not specify behavior when TCP closes/breaks
JS: one way shut down should be specified as legal.
    EOF only when all packets have been processed.
BW: make a note about closing connection in one direction in the 
document.

AP: poors us a cup of coffee.

Include notes about ‘half closing a connection’ (about what to assume and 
what not in this case);
The manager should not assume anything except what can be based on 
responses.

Include explanation about implementation choices whether or not to 
process arrived packets.
Explain about the meaning of responses/replies/informs received 
(authentication and encryption has taken place). 

Harald’s email: the message was about how to explain things.
Conclusion: There is (rough) consensus about not include such detialed 
levels of info in the document.

The AD takes care of getting the next round of coffee.

Conclusions:
------------

- put in text that processing outstanding packets after closing is up to 
the implementer.
- the sending entity should not assume anything about processing or not, 
but rely on normal SNMP operation.
- wording to include about half closed connections.

2.  SNMP payload compression
===========================
The options are:
1. another encryption algorithm
2. use msgFlag bits to signal compression
3. define a new PDUtype
4. (added) (Wes H.) introduce a new security model.
5. (added) (RS) overload the security name: whether compression is used 
or not. This has a simiilar disadvantage as in 1. and it is not an 
architectural clean thing to do (easy to implement though)

Discussion:
-----------

BW: the better it fits in v3 the better it is
JS: the better is fits in v1 the better it is
BW: the PDU solution might be a problem.
JS: but if one has to be done (getSubTreePDU), two can be done as well!?

BW: can live with a new PDU provided that a new PDU for get SubTree is 
needed.

Some procedural proposal:
- select a solution
- propose a compression method
- include option for other compression methods

If you preconfigure compression, you don’t need a new PDU type.

After discussion, the following came out
- First choice: new PDU tpye,
- Second choice msgFlag, 
- Third choice encryption or option 5 or option 4.

First and second choice remain to be chosen from.
All agree with one, under the following consideration: if a new PDU is 
being introduced, then introduce a new PDU type for compression!

Implementation issues:
- no prescription about how to do the compression from the PDU contructed 
or under construction, this is left to the implementation.

3.getSubTree SNMP operation
===========================

BW: suggestion - give a consideration to trick the getBULK, to avoid new 
PDU type discussions.

BW has to leave the meeting.

Dave attends the meeting.

Dave: Include in the document the option to use IPsec for compression.

Question: what if there are multiple subtrees?

AP: subtrees can be very large, that should be allowed. This calls for 
multiple replies (to limit buffer size).

Observation: after a single reply the manager could be noted that there 
is more, it is the manager that asks for the next portion. This is 
another possible scenario.
Advantage is that in case of single threaded agents, it won’t be blocked 
during the getSubTree operation.
Disadvantage is relative large RTT’s.

Everybody agrees that in getSubTree we assume that TCP is being used.

It is not mandatory to return a consistent response to a getSubTree.

Sending multiple responses: set timer for inter packet timeout, a flag 
for the last response.

It should be possible to use getSubTree over UDP.

Question: In case of request retransmission a new request ID should be 
used, or should the same be used?
Solution: current specs recommend (should) to use a new ID for 
retransmissions.

Options: specify MUST, because it’s a new PDU. Or SHOULD with an 
explanation why.

Qs: send multiple responses: TCP is in sequence, UDP we don’t know.
How to indentify the last response, what about error situations.

Question - If an error occurs: should or must be the last response?
Solution: MUST seem to be the appropriate solution.

Quetion: Is it useful that the manager can stop a getSubTree?
Solution: Using TCP you can simply close the connection.

Dave: What about a set for row creation to specify the subtree and the 
agent responds with a bunch of traps contain the subtree?
Conclusion: This is a very good suggestion, which will be studied further 
at a later stage.

Qs: multiple responses over UDP, i.e. sequence numbers number be used, 
where to have them in the PDU?
Possible solutions: 
- An option is to use the error-status (which is unused in this case).
- Put a verbind in each PDU.
- Build a special respond message.
There is preference for the first option

Question: how to code the last PDU?
Possible solution:
- use highest bit of the error status
- .or introduce a new error code
option 2 portentially influences documents such as 190X, 

Question: what’s going to happen when there are holes in a/the subtree?
JS proposes an algorithm to solve this problem (which can be used also in 
the set/trap ‘solution’) and can be easily done by the agent: just return 
‘noSuchInstance’ for te holes.

Intermezzo: (I really had concentrationproblems here, so the minutes do 
not make sense to me ;-)))).

Make an association between oid and ? this has many advantages and really 
adds something (it is really different from the getBULK).

MIB Bowsing: getSubTree(1), you do not get tables as table.
To get tables as table you need to get each column individually.

There is preference for non-repeating repeater.
JS: is it useful to have a timestamp on each ‘fragment’ (i.e. a side 
question made by BJ pops up again ;-)))).
For some variables it could be useful.

End of intermezzo (I think I’m back again).

About sequence numbering:
Use of row-numbers could be helpful for UDP, however we expect things to 
use TCP, therefore there is no need or it.

Asymmetric Compession can be useful in getSubTree: an uncompressed get 
request and a compressed reply.

How to continue:
- implementing & writing an ID should go hand-in-hand.

Next Meeting
============
- We arrange another meeting for later this week to discuss things 
further 
- next meeting is: Thursday July 15, 1999 13:00-15:00.

---
BJ.

From: "J.P. Martin-Flatin" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Reply-To: [email-masked]
Subject: [nmrg] Conserving memory
Date: Wed, 14 Jul 1999 13:21:33 +0200
Sender: [email-masked]

On Fri, 9 Jul 1999 17:35:55 +0200, Juergen Schoenwaelder wrote:
> 
> Jean-Philippe argued for 64K and I said no way. We then started
> lengthy discussions and finally we tried to find a compromise.  I
> started with "lets go with 2K" and we finally ended up with 8K. This
> is after all an arbitrary choice. However, the fact that someone is
> going to support the TCP transport mapping probably means that he
> should have at least some memory available for it. So I still think
> its reasonable (even though I would have preferred a smaller number).

My rationale is that a vendor will not add support for SNMP over TCP
to a box that doesn't have enough memory. If you're tight on memory,
you keep using UDP, even for large transfers. We debated what we mean
by "enough" memory. Because many UDP implementations use a max of 1.5K,
I argued that a max of 2K for TCP was too low: the small gain wasn't
worth the work required for adding support for TCP. I still believe
that we should have picked 64K, which is standard in the TCP realm; but
I'm happy with 8K as a compromise.

For years, the SNMP community had a problem with bottom-of-the-range
boxes and optional SNMP features: the smallest boxes made the rule
because all features had to be supported everywhere. Now that SNMPv3
has broken the deadlock and made optional features a de facto situation
(no one expects all cheap boxes to implement SNMPv3 compression and
security), things may progress now. The concern for small boxes is
valid, but shouldn't prevent us from doing things that make sense in
top-of-the-range boxes. If you want to transfer large amounts of mgmt
data (say 200K), it makes sense to use large TCP buffers (64K).

I find our discussion about buffer sizes slightly anachronistic. People
in the JINI world are now taking for granted that we have a JVM and a
significant amount of software embedded in all the devices that we find
in our day-to-day life: that's what it takes to implement a universal
plug and play (automatic configuration)  that isn't bound to Windows
and that doesn't cost as much as CORBA. Many device vendors have signed
in the JINI concept. The memory requirements of such a scenario render
our discussion obsolete.

> The good thing is that we do not write standards. We can pick a number
> which we think is a reasonable choice to get prototype implementations
> running. We can always change the number if there are people who can
> really convince us that this is a problem for them.

Agreed

Jean-Philippe

____________________________________________________________________
Jean-Philippe Martin-Flatin, EPFL-DI-ICA, 1015 Lausanne, Switzerland
Email: [email-masked]                   Fax: +41-21-693-66-10
Web: http://icawww.epfl.ch/~jpmf/

Date: Mon, 12 Jul 1999 14:40:25 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
CC: [email-masked]
Subject: [nmrg] first Oslo meeting results
Sender: [email-masked]

Below is some stuff I wrote down this morning. I was trying to put
some of the things we have discussed on Sunday into formal ASN.1 and
MIB definitions. This may serve as input for additional ad-hoc
discussions here in Oslo and it allows others on this list to see some
of our results. Members not at the meeting may probably not understand
all the details and reasonings. If you have questions, just ask or
wait until we get the minutes out on this list.

o How do we allocate PDU tags? We should not play with the numbers used
  below because these are the number you want to use in standards and
  not in experiments. So which number space can we use?

o Need to check whether the tag assignements are legal ASN.1 and do
  what I want them to do.

o This is the proposed ASN.1 definition for the compressed PDU:

NMRG-SNMP-COMPRESSED-PDU DEFINITIONS ::= BEGIN

CompressedPDU ::= 		    -- contains a compressed PDU
    [9] IMPLICIT
        OCTET STRING

END

o This is a first sketch of a MIB for configuration of the compression
  algorithm.

o I propose to bind the compression algorithm to the SNMP engine
  rather than a securityName within an SNMP engine. First, I am not
  convinced that it does make sense to support different compression
  algorithms for different users. Furthermore, binding it to the
  securityName (or to the community string and the user name) leads to
  multiple MIB lookups to negotiate the compression algorithm. I
  really would like to be able to do that with a single get request.

NMRG-SNMP-COMPRESSION-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, 
    zeroDotZero, experimental
	FROM SNMPv2-SMI
    MODULE-COMPLIANCE, OBJECT-GROUP
        FROM SNMPv2-CONF;

snmpCompMIB MODULE-IDENTITY
    LAST-UPDATED "9907121100Z"
    ORGANIZATION "IRTF Network Management Research Group"
    CONTACT-INFO
	"Juergen Schoenwaelder
	 TU Braunschweig
	 Bueltenweg 74/75
	 38106 Braunschweig
	 Germany
	 
	 Phone: +49 531 391-3283
	 Email: [email-masked]"
    DESCRIPTION
	"This MIB module defines the SNMP compression MIB."
    ::= { experimental nmrg(91) 2 }

snmpCompObjects     OBJECT IDENTIFIER ::= { snmpCompMIB 1 }
snmpCompConformance OBJECT IDENTIFIER ::= { snmpCompMIB 2 }
snmpCompProtocols   OBJECT IDENTIFIER ::= { snmpCompMIB 3 }

snmpCompCompliances OBJECT IDENTIFIER ::= { snmpCompConformance 1 }
snmpCompGroups      OBJECT IDENTIFIER ::= { snmpCompConformance 2 }

snmpCompNone OBJECT-IDENTITY
    STATUS	current
    DESCRIPTION
	"The trivial no compression protocol."
    ::= { snmpCompProtocols 1 }

snmpCompDeflate OBJECT-IDENTITY
    STATUS	current
    DESCRIPTION
	"Deflate compression protocol as defined in RFC 1951."
    ::= { snmpCompProtocols 2 }

snmpEngineCompProtocol OBJECT-TYPE
    SYNTAX	AutonomousType
    MAX-ACCESS	read-write
    STATUS	current
    DESCRIPTION
	"The compression protocol used by the SNMP engine. The value
         zeroDotZero indicates that the SNMP engine does not support
 	 SNMP compression. The value of this object may be changed
	 to select a different compression protocol. Attempts to set
	 this object to a compression algorithm not supported by the
	 SNMP engine will result in an inconsistentValue error."
    DEFVAL	{ zeroDotZero }
    ::= { snmpCompObjects 1 }

snmpCompCompliance MODULE-COMPLIANCE
    STATUS       current
    DESCRIPTION
	""
    MODULE       -- this module
        MANDATORY-GROUPS { snmpCompGroup }
        OBJECT           snmpEngineCompProtocol
        MIN-ACCESS       read-only
        DESCRIPTION     "Write access is not required."
    ::= { snmpCompCompliances 1 }

nmpCompGroup OBJECT-GROUP
    OBJECTS 	{ snmpEngineCompProtocol }
    STATUS	current
    DESCRIPTION
	""
    ::= { snmpCompGroups 1 }

END

o This is a the proposed ASN.1 definition of the getsubtree PDU and a
  linked response PDU.

o I decided to define a LinkedResponse-PDU as a PDU with a special tag.
  This way, we can use the tag to mark the end of linked responses: You
  receive a stream of LinkedResponse-PDUs and finally exactly one
  Response-PDU. This allows to detect the end of the linked responses
  without having to define a new error-status value and without having
  to play dirty games with the error-index field.

NMRG-SNMP-GETSUBTREE-PDU DEFINITIONS ::= BEGIN

IMPORTS PDU, VarBindList, max-bindings
    FROM SNMPv2-PDU;

GetSubtree-PDU ::= 
    [10] IMPLICIT
        GetSubtreePDU

LinkedResponse-PDU ::=
    [11] IMPLICIT
        PDU

GetSubtreePDU ::=                   -- identical in structure to PDU
    SEQUENCE {
        request-id
            INTEGER (-2147483648..2147483647),

        non-repeaters
            INTEGER (0..max-bindings),

        unused			    -- currently ignored
            INTEGER (0..max-bindings),

        variable-bindings           -- values are ignored
            VarBindList
    }

END

o The example below shows how the "hole algorithm" should work. I
  think we should have additional examples (one with a more complex
  table indexing example and one which shows what happens if you
  send strange requests. 

  getsubtree(ifIndex, ifDescr)

  next(ifIndex, ifDescr) -> ifIndex.1 ifDescr.1 -> use 1
  response(ifIndex.1 = 1, ifDescr.1 = "eth0")

  next(ifIndex.1, ifDescr.1) -> ifIndex.2 ifDescr.4 -> use 2
  response (ifIndex.2 = 2, ifDescr.2 = "NULL")

  next(ifIndex.2, ifDescr.2) -> ifIndex.3 ifDescr.4 -> use 3
  response (ifIndex.3 = 3, ifDescr.3 = "NULL")

  next(ifIndex.3, ifDescr.3) -> ifIndex.4 ifDescr.4 -> use 4
  response (ifIndex.4 = 4, ifDescr.4 = "eth3")

Thats it for now.
							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)

Date: Fri, 9 Jul 1999 18:20:02 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: [nmrg] Work on another implementation of SNMP over TCP
Sender: [email-masked]

>>>>> Ron Sprenkels writes:

Ron> Juergen, is your SNMP over TCP agent on 134.169.34.127 port 161
Ron> still running? We did a telnet to it, but got no response. If it
Ron> is not, is it possible for you to start it again?

I managed to get the TCP code for the CMU Linux agent running again.
The agent is currently running on xxxx.ibr.cs.tu-bs.de port 161.

The agent also does compression of the PDU. The way I do it right now
is not clean (you can't describe it in ASN.1) but I think it is a
helpful prototype for getting numbers how efficient compression really
is. The next step would be to hack compression into the scotty code so
that I can get a better feeling how much savings you get when using
some more complex management tools rather than just plain SNMP
get/getnext operations.
							Juergen

Date: Fri, 9 Jul 1999 17:59:52 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] draft-irtf-nmrg-snmp-compression-00.txt
Sender: [email-masked]

>>>>> Wes Hardaker writes:

[...]

Wes> The last clause in this sentence confuses me. How is compression
Wes> "especially useful" when encryption is used? I don't see any
Wes> benefits for encryption when compression is used.

What I was thinking (and not really writing) was that compression is
especially useful if you use encryption which will make compression
algorithms in the protocol layers below less effective.

Juergen> If both compression and encryption are required, compression
Juergen> MUST be applied before encryption.

Wes> Well I agree that it would be less useful to perform compression
Wes> first, I'm not sure that the word "MUST" is appropriate here. I
Wes> think that using the lowercase version of the word would be a
Wes> better choice.

I agree.

Juergen> 2.2.  Indicating Compression in the msgFlags

Wes> One important detail that is missing from this section is and how
Wes> to select a compression algorithm? Certainly, this information is
Wes> not stored in the flags. So it must be stored somewhere else in
Wes> the packet? In there is no place to do that, unless it is stored
Wes> at the beginning of the compressed data. Either way, it should be
Wes> noted (even though we're not defining the definition, its a
Wes> designing point).

I agree. We need to sort this out.
							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)

Date: Fri, 9 Jul 1999 17:52:11 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] Re: Closing connections - II
Sender: [email-masked]

>>>>> Wes Hardaker writes:

Wes> Does anyone know of a mib node whose definition defines that it
Wes> should change values upon retrieval of its current value?  I
Wes> wouldn't be surprised if something like this existed somewhere.

Things like this exist.
							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)

Date: Fri, 9 Jul 1999 17:35:55 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: [nmrg] draft-irtf-nmrg-snmp-tcp-01.txt (preview)
Sender: [email-masked]

>>>>> Wes Hardaker writes:

Juergen> Since I am not that much interested to start this discussion
Juergen> again, I suggest to keep 8192 until we receive serious
Juergen> complaints from people who really can't implement 8k buffer
Juergen> and who believe that they need to support SNMP over
Juergen> TCP. (BTW, my scotty code currently uses 2k buffers and I
Juergen> have to increase them as well.)

Wes> I assume this is the decision that came out of the last heated
Wes> debate?

Jean-Philippe argued for 64K and I said no way. We then started
lengthy discussions and finally we tried to find a compromise.  I
started with "lets go with 2K" and we finally ended up with 8K. This
is after all an arbitrary choice. However, the fact that someone is
going to support the TCP transport mapping probably means that he
should have at least some memory available for it. So I still think
its reasonable (even though I would have preferred a smaller number).

The good thing is that we do not write standards. We can pick a number
which we think is a reasonable choice to get prototype implementations
running. We can always change the number if there are people who can
really convince us that this is a problem for them.

I think its better to move on now rather than spending even more time
on this constant. [But if you want to have this discussion, you have
to talk with Jean-Philippe. ;-]
							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)

To: [email-masked]
Subject: [nmrg] New compression idea.
Organization: U.C.Davis, Information Technology - D.C.A.S.
From: Wes Hardaker <[email-masked]>
Date: 09 Jul 1999 07:36:09 -0700
Lines: 49
Sender: [email-masked]

I just realized I sent the last note to internet-drafts as well
(sigh).  Sorry about that.

You know, this really isn't an easy problem is it?

Another thought I came up with last night, which I'm not sure I like
much better (but its a though):  We could define a new security model
which would essentially be nothing but an compression wrapper around a
lower security model.

In this sense, the msgSecurityParamaters would be replaced by a
sequence who's last entry was the security parameters sequence of the
lower security module.  IE, something like:

compressSecurityParameters ::=
  SEQUNCE {
    compressionType OBJECT IDENTIFIER
    CHOICE {
      UsmSecurityParameters,
      Other...
    }
  }

Similarly, the ScopedPduData would be the encryptedPDU choice which
would then be handed to the lower security model after uncompression.

It's actually much more complex than that described above, as you have 
to insert something into the lower security model's EoP because of the 
need to auth then compress then encrypt.  This would be hard to
describe generically without referencing the SM in question itself.

+ compliant with the current SNMPv3 specifications (but causes
  problems in that an exact EoP is not possible to describe).
+ combination of M compression and N encryption algorithms possible
  without having to define N*M algorithms.
+ compression can be used with or without encryption or authentication
+ compression of the complete scopedPDU.
- does not work with older versions of SNMP (snmpv1, snmpv2c).

And:

+ You could even encrypt the second Security Models securityParameters 
  if you wanted.

-- 
Wes Hardaker
Distributed Computing Analysis and Support
University of California at Davis

To: Juergen Schoenwaelder <[email-masked]>
Cc: [email-masked], Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] draft-irtf-nmrg-snmp-compression-00.txt
Organization: U.C.Davis, Information Technology - D.C.A.S.
From: Wes Hardaker <[email-masked]>
Date: 09 Jul 1999 07:23:55 -0700
Lines: 29
Sender: [email-masked]

Juergen> Compression is especially useful when retrieving large
Juergen> amounts of data or when SNMP encryption is used.
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The last clause in this sentence confuses me. How is compression
"especially useful" when encryption is used? I don't see any benefits
for encryption when compression is used.

Juergen> If both compression and encryption are required, compression
Juergen> MUST be applied before encryption.

Well I agree that it would be less useful to perform compression
first, I'm not sure that the word "MUST" is appropriate here. I think
that using the lowercase version of the word would be a better choice.

Juergen> 2.2.  Indicating Compression in the msgFlags

One important detail that is missing from this section is and how to
select a compression algorithm? Certainly, this information is not
stored in the flags. So it must be stored somewhere else in the
packet? In there is no place to do that, unless it is stored at the
beginning of the compressed data. Either way, it should be noted (even 
though we're not defining the definition, its a designing point).

-- 
Wes Hardaker
Distributed Computing Analysis and Support
University of California at Davis

To: Juergen Schoenwaelder <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [nmrg] draft-irtf-nmrg-snmp-tcp-01.txt (preview)
Organization: U.C.Davis, Information Technology - D.C.A.S.
From: Wes Hardaker <[email-masked]>
Date: 09 Jul 1999 07:13:30 -0700
Lines: 31
Sender: [email-masked]

>>>>> On Fri, 9 Jul 1999 11:53:29 +0200, Juergen Schoenwaelder <[email-masked]> said:

Juergen> Aiko, Jean-Philippe and I have had heated discussion about this in
Juergen> Boston and I understand your point. However, even UCD SNMP defines

Juergen> #define PACKET_LENGTH   8000

I would comment that this is a recent definition. Previously to the
version 3.6 we were using CMU's original definition which was
somewhere near 1500 bytes.

Juergen> (taken from the 3.6.2 distribution) and that is not too far away from
Juergen> 8192.

My point was that even though I would be willing to implement it, I
don't like mandating this choice to everybody else. I could see
someone in a very small box not wanting to use such a large value.

Juergen> Since I am not that much interested to start this discussion
Juergen> again, I suggest to keep 8192 until we receive serious
Juergen> complaints from people who really can't implement 8k buffer
Juergen> and who believe that they need to support SNMP over
Juergen> TCP. (BTW, my scotty code currently uses 2k buffers and I
Juergen> have to increase them as well.)

I assume this is the decision that came out of the last heated debate?

-- 
Wes Hardaker
Distributed Computing Analysis and Support
University of California at Davis

To: Aiko Pras <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Wes Hardaker <[email-masked]>
Subject: [nmrg] Re: Closing connections - II
Organization: U.C.Davis, Information Technology - D.C.A.S.
From: Wes Hardaker <[email-masked]>
Date: 09 Jul 1999 07:09:07 -0700
Lines: 30
Sender: [email-masked]

>>>>> On Fri, 09 Jul 1999 15:44:02 +0200, Aiko Pras <[email-masked]> said:

Aiko> First I believe you are right that it may be unclear what the agent
Aiko> should do when it finds, while performing a SET, that the underlying
Aiko> connection gets closed. The agent may decide:

Aiko> 1) to go on, but `forget' those parts of the SNMP protocol that
Aiko>    specify that the agent should send a RESPONSE.

Aiko> 2) to stop processing the SET We should probably write down what
Aiko>    kind of agent behaviour we want.

My vote would be to propose something that matched the other
protocol's usage as closely as possible. Therefore, I would suggest
that we mandate that an agent MUST finish processing all requests
received over a socket even if it has already been closed. However, on
the other hand, this is not really necessary for get and getnext
requests (information gathering). It's really only necessary for set
and trap/inform requests (information modifications). Actually,
because an agent might have to include a counter indicating the number
of get requests it has received, it may indeed need to process a
information gathering request. Does anyone know of a mib node whose
definition defines that it should change values upon retrieval of
its current value? I wouldn't be surprised if something like this
existed somewhere.

-- 
Wes Hardaker
Distributed Computing Analysis and Support
University of California at Davis

Date: Fri, 09 Jul 1999 15:57:26 +0200
From: Luca Deri <[email-masked]>
Reply-To: [email-masked]
Organization: Finsiel S.p.A.
To: Aiko Pras <[email-masked]>
CC: "[email-masked]" <[email-masked]>, Wes Hardaker <[email-masked]>
Subject: Re: [nmrg] Re: Closing connections - II
Sender: [email-masked]

Hi all,

> > However, the sentence that I think will cause the most problems is
> > "SNMP engines should not process any outstanding requests if the
> > underlying has closed." This is the sentence that I think is
> > wrong. The one case where I see this causing a really large problem is
> > when an agent is in the middle of processing a set and the agent
> > notices that the TCP connection has been closed, and never performs
> > the function of the set.  This would be a change in behavior from how
I agree.

> First I believe you are right that it may be unclear what the agent
> should do when it finds, while performing a SET, that the underlying
> connection gets closed. The agent may decide:
> 1) to go on, but `forget' those parts of the SNMP protocol that
>    specify that the agent should send a RESPONSE.
> 2) to stop processing the SET
> We should probably write down what kind of agent behaviour we want.
I agree too.

IMHO, you should define some sort of agent behaviour without being too
strict. I could have a SNMP agent that's anynchronous: 
- a thread receives nw requests and returns responses
- another thread dequeues requets and queues responses that will be
handled by the first thread

In this case SET-rollback/cancel or SET-stop might be difficult.

So my suggestion is:
- incomplete requests (i.e. the connection has been closed while
receiving a PDU) are not (obviously) processed
- valid requests are processed regardless of the link state. At worst,
the response/error is not returned to the manager.

Cheers, Luca.

-- 
Luca Deri		 Finsiel S.p.A.
Via Matteucci 34/B	 56124 Pisa, Italy.
Ph. +39/050/968.639      Fax. +39/050/968.626
Email: [email-masked] WWW: http://www.tlcpi.finsiel.it/~deri/
Software is about stuff, about getting hands dirty - Jim Coplien

Date: Fri, 09 Jul 1999 15:44:09 +0200
From: Aiko Pras <[email-masked]>
To: [email-masked], Wes Hardaker <[email-masked]>
CC: Aiko Pras <[email-masked]>
Subject: [nmrg] Re: Closing connections - I
Sender: [email-masked]

Hi all

Wes Hardaker wrote:

> I think I agree with Harald's points. You still need to understand and
> be able to control the layer below you. The advantage of the layering
> scheme is that you don't have to understand all of these layers. Only
> the ones directly below you. I do think we need to more carefully
> consider exactly how SNMP interacts with the TCP layer below it.
My first reaction was that we shouldn't go into the details of the TCP
protocol. However, after thinking about this for a while, I realised
that I was probably to much influenced by my old OSI background, where
we didn't need to map on the underlying protocol, since we had a 
service for that purpose (the socket interface can be seen as the
implementation of one end of the service).

My current feeling is:
a) the socket interface should probably not be regarded as the general 
   abstraction of the TCP protocol layer, since there may be other 
   ways to access TCP)
b) in theory we should specify how we map on the underlying layer. 
   Since we do not have a nice service specification, we should map
   on the underlying protocol.

To get a better feeling on this issue, I decided to take a look at
the specification of other protocols on top of TCP to check how
they specify the mapping on TCP. I took a look at HTTP1.0 and 
1.1 (RFC1945 & 2616), and found that they DIDN'T specify the 
mapping on the underlying TCP packets. If they don't, we should we?

You see, I'm still not sure what we should do

Bye

Aiko

Date: Fri, 09 Jul 1999 15:44:02 +0200
From: Aiko Pras <[email-masked]>
To: "[email-masked]" <[email-masked]>, Wes Hardaker <[email-masked]>
CC: Aiko Pras <[email-masked]>
Subject: [nmrg] Re: Closing connections - II
Sender: [email-masked]

Wes Hardaker wrote:

> However, the sentence that I think will cause the most problems is
> "SNMP engines should not process any outstanding requests if the
> underlying has closed." This is the sentence that I think is
> wrong. The one case where I see this causing a really large problem is
> when an agent is in the middle of processing a set and the agent
> notices that the TCP connection has been closed, and never performs
> the function of the set.  This would be a change in behavior from how
> sets are performed now. Specifically, a manager can issue a set
> without waiting for the response. While this is unwise, it can happen
> in practice. It is still expected that the agent will have completed
> the set.

The case you mention is interesting; there are several aspects we
can discuss.

First I believe you are right that it may be unclear what the agent
should do when it finds, while performing a SET, that the underlying
connection gets closed. The agent may decide:
1) to go on, but `forget' those parts of the SNMP protocol that
   specify that the agent should send a RESPONSE.
2) to stop processing the SET
We should probably write down what kind of agent behaviour we want.

The second aspect relates to the manager behaviour after receiving 
the SET RESPONSE. To my knowledge, after processing the response,
the manager is free to do whatever he likes. In fact he may ignore
the response (although this may not in general be wise). If this is
already possible with the current SNMP, why shouldn't we allow
managers to close the connection immediately after sending the SET?

Aiko

Date: Fri, 9 Jul 1999 11:53:29 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] draft-irtf-nmrg-snmp-tcp-01.txt (preview)
Sender: [email-masked]

>>>>> Wes Hardaker writes:

Wes> That having been said, but I think it would be nice to allow an
Wes> entity to provide service for SNMP over TCP without changing the
Wes> underlying nature of its implementation, which includes its
Wes> buffer sizes. Granted, they will not reap the best of the
Wes> benefits from utilizing TCP, but should we force them to use this
Wes> larger packet size?

Aiko, Jean-Philippe and I have had heated discussion about this in
Boston and I understand your point. However, even UCD SNMP defines

#define PACKET_LENGTH   8000

(taken from the 3.6.2 distribution) and that is not too far away from
8192. ;-) Since I am not that much interested to start this discussion
again, I suggest to keep 8192 until we receive serious complaints from
people who really can't implement 8k buffer and who believe that they
need to support SNMP over TCP. (BTW, my scotty code currently uses 2k
buffers and I have to increase them as well.)
							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)

To: Juergen Schoenwaelder <[email-masked]>
Cc: Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] draft-irtf-nmrg-snmp-tcp-01.txt (preview)
Organization: U.C.Davis, Information Technology - D.C.A.S.
From: Wes Hardaker <[email-masked]>
Date: 08 Jul 1999 22:04:40 -0700
Lines: 19
Sender: [email-masked]

Juergen> When an SNMP entity uses the TCP transport mapping, it MUST be
Juergen> capable of accepting messages that are at least 8192 octets in size.
Juergen> Implementation of larger values is encouraged whenever possible.

I really don't like imposing this limit upon an implementation. I
think, however, this has been discussed here already and I may have
missed the discussion. I'm sorry if that is the case.

That having been said, but I think it would be nice to allow an entity
to provide service for SNMP over TCP without changing the underlying
nature of its implementation, which includes its buffer
sizes. Granted, they will not reap the best of the benefits from
utilizing TCP, but should we force them to use this larger packet
size?
-- 
Wes Hardaker
Distributed Computing Analysis and Support
University of California at Davis

To: Juergen Schoenwaelder <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Closing connections (Re: [nmrg] draft-irtf-nmrg-snmp-tcp-01.txt (preview))
Organization: U.C.Davis, Information Technology - D.C.A.S.
From: Wes Hardaker <[email-masked]>
Date: 08 Jul 1999 22:00:49 -0700
Lines: 37
Sender: [email-masked]

>>>>> On Wed, 16 Jun 1999 17:15:40 +0200, Juergen Schoenwaelder <[email-masked]> said:

Harald> I'm a bit worried about the apparent simplicity of the
Harald> paragraphs on closing connections:

Juergen> There are some interesting points. However, I do not think we
Juergen> have to deal with them. I expect that the average
Juergen> SNMP-over-TCP implementation will be using TCP
Juergen> sockets. Hence, the internal state of the TCP protocol engine
Juergen> is to a large extend invisible. And I think this perfectly
Juergen> reflects reasonable layering.

Let me start off by saying that I am sorry I am responding to these
notes so late. At least, I'm finally getting to them.

I think I agree with Harald's points. You still need to understand and
be able to control the layer below you. The advantage of the layering
scheme is that you don't have to understand all of these layers. Only
the ones directly below you. I do think we need to more carefully
consider exactly how SNMP interacts with the TCP layer below it.

However, the sentence that I think will cause the most problems is
"SNMP engines should not process any outstanding requests if the
underlying has closed." This is the sentence that I think is
wrong. The one case where I see this causing a really large problem is
when an agent is in the middle of processing a set and the agent
notices that the TCP connection has been closed, and never performs
the function of the set.  This would be a change in behavior from how
sets are performed now. Specifically, a manager can issue a set
without waiting for the response. While this is unwise, it can happen
in practice. It is still expected that the agent will have completed
the set.

-- 
Wes Hardaker
Distributed Computing Analysis and Support
University of California at Davis

Date: Thu, 8 Jul 1999 17:31:35 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: [nmrg] Work on another implementation of SNMP over TCP
Sender: [email-masked]

>>>>> Ron Sprenkels writes:

[...]

Ron> Juergen, is your SNMP over TCP agent on 134.169.34.127 port 161
Ron> still running? We did a telnet to it, but got no response. If it
Ron> is not, is it possible for you to start it again?

I can't find it anymore at the moment. It might take a while until I
have something running again.
							Juergen

Date: Thu, 08 Jul 1999 16:55:01 +0200
From: Ron Sprenkels <[email-masked]>
Organization: University of Twente
To: Network Management Research Group <[email-masked]>
CC: Bert Helthuis <[email-masked]>
Subject: [nmrg] Work on another implementation of SNMP over TCP
Sender: [email-masked]

Hi everybody,

Our management group here in twente has recently been extended with a
technician, Bert Helthuis. He is working on an implementation of
draft-irtf-nmrg-snmp-tcp-00.txt, and is in a stage where he could test
against a TCP capable agent.

Juergen, is your SNMP over TCP agent on 134.169.34.127 port 161 still
running? We did a telnet to it, but got no response. If it is not, is it
possible for you to start it again?

thanks,

Ron.

--------------------------------------------------------------------------
Ron Sprenkels  [email-masked]   http://www.cs.utwente.nl/~sprenkel
University of Twente, Department of Computer Science, TSS Management group 
P.O. Box 217, 7500 AE Enschede, The Netherlands.    (Tel. +31 53 489 4663)