Subject: Re: [nmrg] get-subtree already proposed
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Wed, 30 Jun 1999 09:45:37 +0200

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

J> Do you know if the archives of the SNMPv1, SNMPv2 and SNMPv3
J> mailing lists are still accessible? My pointers are obsolete:

J>   http://http-mib.onramp.net/lists/snmp/
J>   http://http-mib.onramp.net/lists/snmpV2/

You should always find a pointer to the official WG archive on the
www.ietf.org charter web page for every active working group. If the
archive does not exist or is incomplete, then you have to contact the
WG chair. [Sure, this does not explain how you find archives of WGs
that have concluded.]

J> Reportedly, the issue of a get-subtree operation was already
J> discussed in 1996 on one of these lists. See:

Sure. But nobody ever went so far to really define and implement it. I
hope this group will do this so that we can start using it to solve
problems and to get experience how it works in practice.

							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: "J.P. Martin-Flatin" <[email-masked]>
To: [email-masked]
cc: [email-masked]
Reply-To: [email-masked]
Subject: [nmrg] get-subtree already proposed
Date: Tue, 29 Jun 1999 18:37:13 +0200
Sender: [email-masked]

Do you know if the archives of the SNMPv1, SNMPv2 and SNMPv3 mailing
lists are still accessible? My pointers are obsolete:

  http://http-mib.onramp.net/lists/snmp/
  http://http-mib.onramp.net/lists/snmpV2/

Reportedly, the issue of a get-subtree operation was already discussed
in 1996 on one of these lists. See:

  P. Mullaney. "Overview of a Web-based Agent". The Simple Times,
  Vol. 4, No. 3, July 1996.

  "Current SNMP operations over HTTP could then take advantage of the
  protocol's ability to transfer large amounts of information, and a
  new get-subtree operation could also be defined to explicitly take
  advantage of this feature, as is currently under discussion on the
  SNMP mailing list."

In the same issue, another article also referred to get-subtree, so
apparently this new operation was hot in those days:

  C. Wellens and K. Auerbach. "Towards Useful Management". The Simple
  Times, Vol. 4, No. 3, July 1996.

  "However, the real issue is whether we really need the get* trinity
  at all. The get operation is the only silver-bullet of the three
  SNMP retrieval operations; the latter two are merely means to get
  past SNMP's limited data unit imposed by the myth of ``The Collapsing
  Network''. As such, all three retrieval operations could be collapsed
  into a single get-subtree operator that takes a single parameter, an
  object identifier, and returns all objects which are prefixed by that
  OID. For convenience, we ought to define the subtree traversal to
  return the objects in lexicographic order; and, for efficiency, we
  should allow a list of prefixes and allow the return of multiple
  sub-trees."

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: Thu, 24 Jun 1999 17:58:40 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] two bug fixes in draft-irtf-nmrg-snmp-tcp-01.txt
Sender: [email-masked]

Simon Leinen <[email-masked]> found the following bug in
<draft-irtf-nmrg-snmp-tcp-01.txt>:

    It is RECOMMENDED that administrators configure their SNMP entities
-   containing command generators to listen on TCP port 161 for incoming
+   containing command responders to listen on TCP port 161 for incoming
    connections. It is also RECOMMENDED that SNMP entities containing
    notification receivers be configured to listen on TCP port 162 for

I have replaced command generators with command responders as
indicated above. I also changed the year in the copyright notice to
1999. I do not intend to issue a new ID - I plan to submit a new one
after our meeting in Oslo.
							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, 24 Jun 1999 09:50:44 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: [nmrg] Wildcarding & Query Processing
Sender: [email-masked]

>>>>> Luca Deri writes:

Luca> Hi Wes,

Luca> Wes Hardaker wrote: In addition how would you handle
Luca> 'get-subtree(1.3.*.161)'?
>>  I'd yell at the person that made such a lousy request...
>> 
>> More seriously, it probably should be implementation dependent what
>> it's willing to handle?

Luca> The suggested protocol modification (get-subtree) allows
Luca> requests as the one above, hence IMHO you have two choices: -
Luca> protocol error (e.g. you can return an error such as 'complexity
Luca> limitation') or - you handle the request somehow.

I do not think that we already have agreement on the details of
get-subtree. I do not remember that we had a decision to support
wildcarding nor do I remember a good proposal to implement
wildcards. (I do not consider bit masks for every varbind an
"appealing proposal". ;-)

Anyway, I hope we can make some progress on get-subtree in Oslo and
here on the mailing list. So don't read this response as a message to
stop discussions. I actually appreciate input for get-subtree. But we
need to get down to the nasty details how get-subtree should work.
People interested in wildcarding capabilities should try to come up
with concrete proposals how to encode wildcards (multiple alternatives
may be a good start for discussions) and they should probably think a
little bit how wildcarding interacts with typical agent/subagent
implementations and VACM.
							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, 24 Jun 1999 08:55:48 +0200
From: Luca Deri <[email-masked]>
Reply-To: [email-masked]
Organization: Finsiel S.p.A.
To: Wes Hardaker <[email-masked]>
CC: [email-masked]
Subject: Re: [nmrg] Wildcarding & Query Processing
Sender: [email-masked]

Hi Wes,

Wes Hardaker wrote:
> Luca> In addition how would you handle 'get-subtree(1.3.*.161)'?
> 
> I'd yell at the person that made such a lousy request...
> 
> More seriously, it probably should be implementation dependent what
> it's willing to handle?

The suggested protocol modification (get-subtree) allows requests as the
one above, hence IMHO you have two choices:
- protocol error (e.g. you can return an error such as 'complexity
limitation')
or
- you handle the request somehow.

The message of my mail was: the get-subtree as it was proposed allows
people to issue such weird requests. So if you're going to push
get-subtree() then make sure you can handle all the possible requests.

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: Tue, 22 Jun 1999 10:58:12 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: Network Management Research Group <[email-masked]>
Subject: [nmrg] draft-irtf-nmrg-snmp-compression-00.txt
Sender: [email-masked]

Cynthia, please post the attached document as Internet Draft
<draft-irtf-nmrg-snmp-compression-00.txt>. This document is the result
of the network management research group of the IRTF.

							Juergen

Network Working Group                           J. Schoenwaelder, Editor
Internet-Draft                                           TU Braunschweig
Expires December 1999                                       20 June 1999

                        SNMP Payload Compression

               <draft-irtf-nmrg-snmp-compression-00.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups. Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   Distribution of this document is unlimited. Please send comments to
   the Network Management Research Group <[email-masked]>.

Copyright Notice

   Copyright (C) The Internet Society (1999). All Rights Reserved.

Abstract

   This memo defines a mechanism for lossless compression of SNMP
   payloads. Compression is especially useful when retrieving large
   amounts of data or when SNMP encryption is used.

J. Schoenwaelder                                                [Page 1]

Internet-Draft          SNMP Payload Compression               June 1999

   Table of Contents

   1 Introduction .................................................    3
   2 Requirements and Alternatives ................................    3
   2.1 Compression as an SNMPv3 Encryption Algorithm ..............    3
   2.2 Indicating Compression in the msgFlags .....................    4
   2.3 Compression as a new PDU type ..............................    4
   3 Acknowledgments ..............................................    6
   4 References ...................................................    6
   5 Editor's Address .............................................    6
   6 Full Copyright Statement .....................................    7

J. Schoenwaelder                                                [Page 2]

Internet-Draft          SNMP Payload Compression               June 1999

1.  Introduction

   This memo defines a mechanism for lossless compression of SNMP
   payloads. Compression is useful when retrieving large amounts of
   management data since the BER encoding used by SNMP is not very space
   efficient and the data tends to have a high degree of redundancy.

   SNMP payload compression is especially useful when SNMP encryption is
   used. Encrypting the SNMP payload causes the data to be random in
   nature, rendering compression at lower protocol layers (e.g., IP
   Payload Compression Protocol [2]) ineffective. If both compression
   and encryption are required, compression MUST be applied before
   encryption.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].

2.  Requirements and Alternatives

   A solution for SNMP payload compression has to satisfy the following
   requirements:

   - Compression must happen before encryption if compression is used
     together with encryption. Compression is most useful if there are
     regular pattern in the data. It is the nature of encryption
     algorithms to destroy any regular pattern and hence encrypted data
     does not compress very well.

   - SNMP payload compression should support multiple compression
     algorithms. This means that communicating SNMP engines must be able
     to find agreement on the compression algorithm they are using.
     Instead of carrying compression algorithm identifier in every
     protocol message, it seems more effective to indicate compression
     algorithms in a MIB module (similar to authentication or encryption
     algorithms in SNMPv3).

2.1.  Compression as an SNMPv3 Encryption Algorithm

   The basic idea behind the first alternative is to treat compression
   as an SNMPv3 encryption algorithm. This has the following advantages
   / disadvantages:

   +  No change required to the SNMPv3 specifications.

   -  Support of N encryption algorithms and M compression algorithms
      leads to N*M possible combinations.

J. Schoenwaelder                                                [Page 3]

Internet-Draft          SNMP Payload Compression               June 1999

   -  Compression requires authentication since there is no noAuthPriv
      security level.

   +  Compression of the complete ScopedPDU.

   -  Does not work with older versions of SNMP (SNMPv1, SNMPv2c).

2.2.  Indicating Compression in the msgFlags

   To avoid some of the drawbacks of the previous approach, one can
   treat compression independent of encryption by allocating an unused
   bit in the msgFlags [3] to indicate whether compression is used or
   not. However, RFC 2572 [3] says in section 6.4:

      The remaining bits in msgFlags are reserved, and MUST be set to
      zero when sending a message and SHOULD be ignored when receiving
      a message.

   Similarly, RFC 2572 [3] specifies in section 7.1 step 7) and in
   section 7.2 step 5) that other bits msgFlags are set to zero or
   ignored. This means that this alternative can not be supported by an
   implementation which is compliant to RFC 2572 [3].

   In summary, this approach has the following advantages /
   disadvantages:

   -  Not strictly compliant to the current SNMPv3 specifications.

   +  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).

2.3.  Compression as a new PDU type

   The third alternative is to restrict compression to PDUs rather than
   ScopedPDUs and to introduce a new PDU type for compressed payloads.
   RFC 1157 [4] defines the SNMPv1 message header as follows:

       Message ::= SEQUENCE {
           version   INTEGER { version-1(0) },
           community OCTET STRING,

J. Schoenwaelder                                                [Page 4]

Internet-Draft          SNMP Payload Compression               June 1999

           data      ANY  -- e.g., PDUs if trivial authentication
                          -- is being used
       }

   Similarly, RFC 2572 [3] defines the ScopedPDU as follows:

       ScopedPDU ::= SEQUENCE {
           contextEngineID  OCTET STRING,
           contextName      OCTET STRING,
           data             ANY -- e.g., PDUs as defined in RFC 1905
       }

   This means that a new PDU could be defined which holds the compressed
   version of a PDU:

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

   Its important to analyze how a compliant SNMP implementation behaves
   when it receives an unknown PDU type. From a formal point of view,
   any PDU which is a valid BER serialization of an ASN.1 type must be
   accepted since the data portion is of the ASN.1 type ANY. In
   practice, most SNMP implementations will only recognize the PDU types
   defined in the SNMP specifications.

   The SNMPv3 message processing model [3] defines in section 7.2 step
   7) that parse errors while decoding the ScopedPDU cause the packet to
   be discarded after incrementing snmpInASNParseErrs. Even an
   implementation which is capable to decode arbitrary PDUs will have
   problems to determine the pduType as defined in section 7.2 step 9).
   This basically means that a compliant SNMPv3 engine will simply
   discard compressed PDUs.

   The SNMPv1 specification [4] defines in section 4.1 second step (4)
   that parse errors while decoding the PDU will cause the SNMP engine
   to drop the PDU. Hence, it can be expected that most implementations
   will simply drop a compressed PDU.

   In summary, this approach has the following advantages /
   disadvantages:

   -  Not strictly compliant to the current SNMPv3 specifications.

   +  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.

J. Schoenwaelder                                                [Page 5]

Internet-Draft          SNMP Payload Compression               June 1999

   -  Compression of the PDU rather than the ScopedPDU.

   +  Works with every version of SNMP.

3.  Acknowledgments

   This document is the result of discussions of the Network Management
   Research Group (NMRG). Special thanks go to the following
   participants for their comments and contributions:

   Luca Deri, Jean-Philippe Martin-Flatin, Aiko Pras, Ron Sprenkels,
   Bert Wijnen.

4.  References

[1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
     Levels", BCP 14, RFC 2119, March 1997.

[2]  Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP Payload
     Compression Protocol (IPComp)", RFC 2393, December 1998.

[3]  Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message
     Processing and Dispatching for the Simple Network Management
     Protocol (SNMP)", RFC 2572, April 1999.

[4]  Case, J., Fedor, M., Schoffstall, M. and J. Davin, "A Simple
     Network Management Protocol (SNMP)", RFC 1157, May 1990.

5.  Editor's Address

     Juergen Schoenwaelder
     TU Braunschweig
     Bueltenweg 74/75
     38106 Braunschweig
     Germany

     Phone: +49 531 391-3283
     EMail: [email-masked]

J. Schoenwaelder                                                [Page 6]

Internet-Draft          SNMP Payload Compression               June 1999

6.  Full Copyright Statement

   Copyright (C) The Internet Society (1999). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

J. Schoenwaelder                                                [Page 7]

Date: Tue, 22 Jun 1999 10:34:25 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] [Fwd: Authorship, CRC Press]
Sender: [email-masked]

>>>>> Luca Deri writes:

Luca> Bear in mind that although you don't see me I follow your
Luca> discussions.

Good to know.

Luca> Now a question. I've received the mail below.

[...]

Luca> A book on nw mgmt is definitively a very appealing idea. I'm
Luca> wondering whether some of you is interested too so we can do a
Luca> join work. Please let me know.

I guess nearly everybody has received this email. This does not
convince me that this is a serious effort. (I can't believe that you
can plan good books by discussing the title.)

I agree that a good reference and educational book on network
management is missing. But writing such a beast takes an enormous
amount of time and I am afraid that my schedule does not allow to do
it.
							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: Tue, 22 Jun 1999 08:28:12 +0200
From: Luca Deri <[email-masked]>
Reply-To: [email-masked]
Organization: Finsiel S.p.A.
To: NMRG Mailing List <[email-masked]>
Subject: [nmrg] [Fwd: Authorship, CRC Press]
Sender: [email-masked]

Hi all,
I'm back at work after my wedding. I've tried to follow your discussions
on the mailing list. I see that things are moving but I'm very sad not
to have the chance to join you in Oslo. Bear in mind that although you
don't see me I follow your discussions.

Now a question. I've received the mail below.
> 
> Dear Luca Deri,
> I understand you are an expert in the field of Communications Technologies.
> 
> I am the Series Editor-in-Chief of the "Advanced and Emerging Communications
> Technologies: A Desk Reference Series", CRC Press, and would like you to
> consider the possibility of authoring a book on SNMP or another
> communication-related title of your choice.   If you would be interested in
> this opportunity, please e-mail back to [email-masked]. Thank you.
> 
> Sincerely,
> Saba Zamir

A book on nw mgmt is definitively a very appealing idea. I'm wondering
whether some of you is interested too so we can do a join work. Please
let me know.

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, 18 Jun 1999 17:44:35 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Subject: [nmrg] meeting details for Oslo
Sender: [email-masked]

Here are some more details for our meeting in Oslo. I managed to
organize a meeting room at the University of Oslo. I propose to start
the meeting at 10 am (10:00) and I think we should be done at 5 pm
(17:00). The purpose of this meeting is to finish our work on bulk
data transfer: 

 o Discuss any open issues with regard to the SNMP over TCP document. 
 o Discuss and select an approach for SNMP payload compression. 
 o Work out the details of the GetSubTree protocol operation. 

I will post the revised SNMP over TCP draft in the next minutes. The
only open issue we have is the point raised by Harald. I also plan 
to write up a short summary for the compression options we have
identified so far before the ID cutoff date.

More details about the meeting place and how to get there are now
available from the NMRG web site. You may want to go directly to
<URL:http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/1999/oslo/>.

							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, 17 Jun 1999 15:49:27 +0200
To: Juergen Schoenwaelder <[email-masked]>
From: Harald Tveit Alvestrand <[email-masked]>
Subject: Re: Closing connections (Re: [nmrg] draft-irtf-nmrg-snmp-tcp-01.txt (preview))
Cc: [email-masked]
Sender: [email-masked]

At 17:15 16.06.99 +0200, Juergen Schoenwaelder wrote:

> >>>>> Harald Tveit Alvestrand writes:
>
>Harald> I'm a bit worried about the apparent simplicity of the
>Harald> paragraphs on closing connections:
>
>[...]
>
>There are some interesting points. However, I do not think we have to
>deal with them. I expect that the average SNMP-over-TCP implementation
>will be using TCP sockets. Hence, the internal state of the TCP
>protocol engine is to a large extend invisible. And I think this
>perfectly reflects reasonable layering.

Jurgen,
that may mean you are writing your standards to an API, and not to the
underlying protocol. This is dangerous.

In particular, TCP connections have 2 directions, which close independently.
This is also reflected in the Socket API, through the "shutdown" call.
Unfortunately many TCP programmers will use the "close" call on a socket,
which works perfectly well, but may cause the programmer to forget that
there are other options.

>If you are saying that every protocol on top of TCP should consider
>the internal TCP state when e.g. closing a connection, then we are in
>real trouble. Fortunately, I am using so many protocols on top of TCP
>every day that do not play with internal TCP states and things usually
>run fine...

"usually run fine" doesn't seem to me like a ringing recommendation....
in this particular case, we need to decide whether or not a command responder
should flush the queue of pending actions (if it has them) when it sees
a normal EOF mark on the input stream on a socket (I think it should not),
or when it gets an indication of error on that same socket (I think it
should).

I think it's clearer to specify this in terms of the SYN, FIN and RST
bits (observable on the wire) than in terms of the Socket API calls.
But opinions may vary.

>Harald> But must shut down now - plane is landing....
>
>Wish you a nice stay...

the plane was carrying me home  :-)
(but that's where I wanted to be)

Have fun!

                       Harald A

--
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

Date: Wed, 16 Jun 1999 17:15:40 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Closing connections (Re: [nmrg] draft-irtf-nmrg-snmp-tcp-01.txt (preview))
Sender: [email-masked]

>>>>> Harald Tveit Alvestrand writes:

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

[...]

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

If you are saying that every protocol on top of TCP should consider
the internal TCP state when e.g. closing a connection, then we are in
real trouble. Fortunately, I am using so many protocols on top of TCP
every day that do not play with internal TCP states and things usually
run fine...

Harald> But must shut down now - plane is landing....

Wish you a nice stay...
							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: Tue, 15 Jun 1999 16:42:54 +0200
To: Juergen Schoenwaelder <[email-masked]>, Network Management Research Group <[email-masked]>
From: Harald Tveit Alvestrand <[email-masked]>
Subject: Closing connections (Re: [nmrg] draft-irtf-nmrg-snmp-tcp-01.txt (preview))
Sender: [email-masked]

No, I'm not really here....I just wander by to see how you're doing
occasionally. Keep on truckin'!

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

>    All SNMP entities (whether in an agent role or manager role) can
>    close TCP connections at any point in time. This ensures that SNMP
>    entities can control their resource usage and shut down TCP
>    connections that are not used. SNMP engines SHOULD NOT process any
>    outstanding requests if the underlying TCP connection has been
>    closed. A `noResponse' error condition SHOULD be signalled for
>    outstanding requests for command generator applications if the TCP
>    connection is closed before a response has been received.

Here there are a number of cases.
For instance: Consider the following sets of packets received by
a command responder:

   SYN, Request -  MUST be replied to (normal case).

   SYN, Request, FIN -  should STILL be replied to, even though
        connection is "closed" - the other direction is open.
        But FIN must follow last byte sent.

   SYN, Request, RST -  MUST NOT be replied to; the other end is
        signalling that it's lost track or isn't there any more
        (the RST may be in response to the ACK on the first packet of
        the request). This is also the only case I can think of where
        the "SHOULD NOT process" text can apply.

   SYN, Half-packet, FIN - MUST NOT be replied to; won't ever be complete.

In the same vein, the command generator application may see:

   Request->       Normal case
   <- Response

   Request->         Other end decided to close connection
   <- Response, FIN  Note: Time may pass between response and FIN.

   Request->
   <- RST          Error, other end has died brutally

   Request->
   <- FIN, (RST)   Other end closed connection normally, but the FIN packet
                   didn't get to you until you had sent the next request.
                   This WILL happen in practice; "noResponse" may be wrong
                   here, since reestablishing the connection may give you
                   a perfectly good answer.

   Request->
   <- No response  Error, connectivty lost. WILL happen in practice,
                   MUST time out. Does the standard need to specify a
                   default timeout? (Urgh....a MIB????)

There are also a couple of issues with flow control; you probably want to
disable use of the NAGLE algorithm - good literature is available on these
problems as seen from HTTP.

But must shut down now - plane is landing....

                          Harald

--
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

From: "J.P. Martin-Flatin" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: [nmrg] meeting in Oslo 
Date: Mon, 14 Jun 1999 15:55:01 +0200
Sender: [email-masked]

On Fri, 11 Jun 1999 17:21:23 +0200, Juergen Schoenwaelder wrote:
> 
> There will be a meeting of this group in Oslo.
> 
> We discussed in Boston to plan for a one day meeting on Sunday before
> the IETF starts. This has the advantage that our minds are still fresh
> and that we can go to a nice reception once the meeting is over. I
> need to get feedback from you about who will be able to attend so that
> I can arrange for a meeting room.

Unfortunately, I can't attend this meeting.

____________________________________________________________________
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, 14 Jun 1999 13:43:00 +0200
From: Aiko Pras <[email-masked]>
To: Juergen Schoenwaelder <[email-masked]>
CC: Network Management Research Group <[email-masked]>, Ron Sprenkels <[email-masked]>, Bert-Jan van Beijnum <[email-masked]>, Henk Eertink <[email-masked]>, Aiko Pras <[email-masked]>
Subject: Re: [nmrg] meeting in Oslo
Sender: [email-masked]

Juergen Schoenwaelder wrote:
> 
> There will be a meeting of this group in Oslo.
> 
> We discussed in Boston to plan for a one day meeting on Sunday before
> the IETF starts. This has the advantage that our minds are still fresh
> and that we can go to a nice reception once the meeting is over. I
> need to get feedback from you about who will be able to attend so that
> I can arrange for a meeting room.

I just reserved rooms in the Rainbow Astoria Hotel
(http://www.scantours.com/astoria_hotel_oslo.htm / tel: +47 22 42 00 10) 
for Bert-Jan, Ron and me. We will arrive saturday 10 July, and depart
friday 16 july.

Bye

Aiko

Date: Fri, 11 Jun 99 19:01:24 DST
From: "Bert Wijnen" <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: [nmrg] meeting in Oslo
Sender: [email-masked]

Ref:  Your note of Fri, 11 Jun 1999 17:21:23 +0200

Subject: Re:   [nmrg] meeting in Oslo

I am not sure yet:
- If I will be in OSLO early on Sunday (I may have personal obligations
  at home ... I am trying to figure out).
- If I am in OSLO... other IESG/IETF related issues may need my
  attention.

But in principle I agree to have a meeting and I will try to be there.

Bert

Date: Fri, 11 Jun 1999 17:31:05 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] Bulk transfer of mib data - SimpleTimes article
Sender: [email-masked]

>>>>> Sudhir Pendse writes:

Sudhir> A few years ago, I had posted an article to the snmp mailing
Sudhir> list (it is attached below) that described a MIB based
Sudhir> approach for enhancing SNMP. Just has the RMON mib has a
Sudhir> control table and a data table, it proposed a BULKDATA mib
Sudhir> that had a request table, and a data table.

Sudhir> After reading your article, the proposed scheme is very
Sudhir> similar to the hybrid approach suggested by Stewart, except it
Sudhir> does not use ftp, not does it need a proprietary oid encoding
Sudhir> scheme, but it does use "encoded octet strings".

Thanks for pointing us to this MIB fragment.

Sudhir> I am sure that the scheme described below needs a lot of
Sudhir> improvements, and infact reading it again, after a few years,
Sudhir> even I can think of a few enhacements.(like using something
Sudhir> like the cbfDefineObjectTable to make it more generic, or
Sudhir> accesing the number of columns in a table more easily....)

We currently looking at ways to specify and hopefully implement /
prototype approach #1 (extending SNMP) rather than doing the hybrid
approach. I believe that the right place to fix the performance
problem of the protocol is in the protocol.

Sudhir> Anyways, I would be most interested in participating in this
Sudhir> research group activities on this topic.  Please let me know
Sudhir> what procedures to follow.

We plan for a meeting where we will discuss the details of SNMP
compression and getsubtree. This meeting is planned to take place on
Sunday just before the Oslo IETF meeting. You are welcome to join us
if you are going to be in Oslo at that time.
							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, 11 Jun 1999 17:30:38 +0200
From: Ron Sprenkels <[email-masked]>
Organization: University of Twente
To: Juergen Schoenwaelder <[email-masked]>
CC: Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] meeting in Oslo
Sender: [email-masked]

Hi,

> There will be a meeting of this group in Oslo.
> 
> We discussed in Boston to plan for a one day meeting on Sunday before
> the IETF starts. This has the advantage that our minds are still fresh
> and that we can go to a nice reception once the meeting is over. I
> need to get feedback from you about who will be able to attend so that
> I can arrange for a meeting room.

Meeting on sunday is fine with me, I'll be there.

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)

Date: Fri, 11 Jun 1999 17:21:23 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
CC: [email-masked]
Subject: [nmrg] meeting in Oslo
Sender: [email-masked]

There will be a meeting of this group in Oslo.

We discussed in Boston to plan for a one day meeting on Sunday before
the IETF starts. This has the advantage that our minds are still fresh
and that we can go to a nice reception once the meeting is over. I
need to get feedback from you about who will be able to attend so that
I can arrange for a meeting room.

The agenda for this meeting will include discussions on how to do SNMP
compression (see the minutes for the options we have so far) and how
to define the getsubtree operation we talked about in Lausanne. We may
address other topics as well (e.g. SMIng) as time permits.

							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, 11 Jun 1999 17:13:22 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] draft-irtf-nmrg-snmp-tcp-01.txt (preview)
Sender: [email-masked]

Below is a new revision of the SNMP-over-TCP Transport Mapping
document for review. It contains the changes discussed in Boston. I
will post this as an ID if I do not receive any objections til
Wednesday 16 June 1999.
							Juergen

Network Working Group                           J. Schoenwaelder, Editor
Internet-Draft                                           TU Braunschweig
Expires December 1999                                       10 June 1999

                    SNMP-over-TCP Transport Mapping

                   <draft-irtf-nmrg-snmp-tcp-01.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.  Internet-Drafts are
   working documents of the Internet Engineering Task Force (IETF), its
   areas, and its working groups. Note that other groups may also
   distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   Distribution of this document is unlimited. Please send comments to
   the Network Management Research Group, <[email-masked]>.

Copyright Notice

   Copyright (C) The Internet Society (1999). All Rights Reserved.

Abstract

   This memo defines a transport mapping for using the Simple Network
   Management Protocol (SNMP) over TCP. The transport mapping defined in
   this memo can be used with any version of SNMP.

J. Schoenwaelder                                                [Page 1]

Internet-Draft      SNMP-over-TCP Transport Mapping            June 1999

   Table of Contents

   1 Introduction .................................................    3
   2 Definitions ..................................................    3
   3 SNMP over TCP ................................................    4
   3.1 Serialization ..............................................    4
   3.2 Well-Known Values ..........................................    4
   3.3 Connection Management ......................................    5
   4 Acknowledgments ..............................................    5
   5 References ...................................................    6
   6 Editor's Address .............................................    6
   7 Full Copyright Statement .....................................    7

J. Schoenwaelder                                                [Page 2]

Internet-Draft      SNMP-over-TCP Transport Mapping            June 1999

1.  Introduction

   This memo defines a transport mapping for using the Simple Network
   Management Protocol (SNMP) over TCP. The transport mapping defined in
   this memo can be used with any version of SNMP. This document extends
   the transport mappings defined in RFC 1906 [1].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [2].

2.  Definitions

   IRTF-NMRG-SNMP-TM DEFINITIONS ::= BEGIN

   IMPORTS
       MODULE-IDENTITY, OBJECT-IDENTITY, experimental
           FROM SNMPv2-SMI
       TEXTUAL-CONVENTION
           FROM SNMPv2-TC;

   nmrgSnmpDomains MODULE-IDENTITY
       LAST-UPDATED "9906101100Z"
       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-over-TCP transport mapping."
       ::= { experimental nmrg(91) 1 }

   -- SNMP over TCP over IPv4

   snmpTCPDomain   OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION
           "The SNMP-over-TCP-over-IPv4 transport domain. The
            corresponding transport address is of type SnmpTCPAddress."
       ::= { nmrgSnmpDomains 6 }   -- matches first unused value
                                   -- below snmpDomains

   SnmpTCPAddress ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "1d.1d.1d.1d/2d"

J. Schoenwaelder                                                [Page 3]

Internet-Draft      SNMP-over-TCP Transport Mapping            June 1999

       STATUS       current
       DESCRIPTION
               "Represents a TCP/IPv4 address:

                  octets   contents        encoding
                   1-4     IP-address      network-byte order
                   5-6     TCP-port        network-byte order
               "
       SYNTAX      OCTET STRING (SIZE (6))

   END

3.  SNMP over TCP

   SNMP over TCP is an optional transport mapping. Implementors are
   encouraged to support SNMP over TCP whenever possible because this
   enables applications to make more efficient bulk transfers of MIB
   data [3].

   The originator of a request/response transaction chooses the
   transport protocol for the entire transaction. The transport protocol
   MUST NOT change during a transaction.

   In general, originators of request/response transactions are free to
   use the transport they assume is the best in a given situation.
   However, as TCP has a larger footprint on resource usage than UDP,
   applications using SNMP over TCP may choose to switch back to UDP by
   refusing new TCP connections whenever necessary (e.g. too many open
   TCP connections).

3.1.  Serialization

   Each instance of a message is serialized into a single BER-encoded
   message, using the algorithm specified in Section 8 of RFC 1906 [1].
   The BER-encoded message is then sent over a TCP connection.

   It is possible to exchange multiple SNMP request/response pairs over
   a single (persistent) TCP connection. The length field in the BER-
   encoded SNMP message is used to separate multiple requests sent over
   a single TCP connection.

3.2.  Well-Known Values

   It is RECOMMENDED that administrators configure their SNMP entities
   containing command generators to listen on TCP port 161 for incoming
   connections. It is also RECOMMENDED that SNMP entities containing
   notification receivers be configured to listen on TCP port 162 for

J. Schoenwaelder                                                [Page 4]

Internet-Draft      SNMP-over-TCP Transport Mapping            June 1999

   connection requests.

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

3.3.  Connection Management

   The use of TCP connections introduces costs. Connection establishment
   and teardown cause additional network traffic. Furthermore,
   maintaining open connections binds resources in the network layer of
   the underlying operating system.

   TCP connections are intended to be used when the size of the
   transferred data is large. If a connectionless transport were used
   instead, its small packet-size constraint would cause latency to
   increase excessively.

   Another advantage of using TCP connections, regardless of the message
   size, is that you do not need to implement retransmissions at the
   application level. This may result in simpler management
   applications.

   All SNMP entities (whether in an agent role or manager role) can
   close TCP connections at any point in time. This ensures that SNMP
   entities can control their resource usage and shut down TCP
   connections that are not used. SNMP engines SHOULD NOT process any
   outstanding requests if the underlying TCP connection has been
   closed. A `noResponse' error condition SHOULD be signalled for
   outstanding requests for command generator applications if the TCP
   connection is closed before a response has been received.

4.  Acknowledgments

   The definitions in this memo are inspired by definitions found in RFC
   1906 [1]. This document is the result of discussions of the Network
   Management Research Group (NMRG). Special thanks go to the following
   participants for their comments and contributions:

   Luca Deri, Jean-Philippe Martin-Flatin, Aiko Pras, Ron Sprenkels,
   Bert Wijnen.

J. Schoenwaelder                                                [Page 5]

Internet-Draft      SNMP-over-TCP Transport Mapping            June 1999

5.  References

   [1]  Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
        "Transport Mappings for Version 2 of the Simple Network
        Management Protocol (SNMPv2)", RFC 1906, January 1996.

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [3]  Sprenkels, R., and J.P. Martin-Flatin, "Bulk Transfers of MIB
        Data", The Simple Times, Vol. 7, No. 1, pp. 1-7, March 1999.

6.  Editor's Address

   Juergen Schoenwaelder
   TU Braunschweig
   Bueltenweg 74/75
   38106 Braunschweig
   Germany

   Phone: +49 531 391-3283
   EMail: [email-masked]

J. Schoenwaelder                                                [Page 6]

Internet-Draft      SNMP-over-TCP Transport Mapping            June 1999

7.  Full Copyright Statement

   Copyright (C) The Internet Society (1998). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

J. Schoenwaelder                                                [Page 7]

From: "J.P. Martin-Flatin" <[email-masked]>
To: [email-masked]
cc: [email-masked]
Reply-To: [email-masked]
Subject: [nmrg] Minutes of the 2nd NMRG meeting
Date: Thu, 10 Jun 1999 18:22:46 +0200
Sender: [email-masked]

The 2nd NMRG meeting took place in Boston, MA, USA on May 23 and 26,
in parallel to IM'99. Duration = 2 * 0.5 day.

Present:

 * Juergen Schoenwaelder (JS)
 * Aiko Pras (AP)
 * Jean-Philippe Martin-Flatin (JPMF)

Agenda:

 * draft-irtf-nmrg-snmp-tcp-00.txt
 * compression
 * SMIng
 * long-term aim of NMRG
 * how should NMRG operate?
 * next NMRG meetings

Minutes:

1) draft-irtf-nmrg-snmp-tcp-00.txt
   ===============================

* We are not far from completing this draft. We went through the
  comments that JPMF sent to the NMRG mailing list (NMRGml) on May 7.

* The new section 3.3 should be rephrased (e.g. "UDP connections" is
  a contradiction). JS typed in a new text we all agreed with. JPMF's
  idea that this RFC should not explicitly limit the use of TCP to
  bulk data transfers was accepted. AP proposed a new wording for the
  retransmissions with which we all agreed.

* Use of MUST, SHOULD, CAN...: JS will decide when to capitalize these
  words.

* What should be the minimum size guaranteed to be accepted by all
  entities? We had a long discussion to find a good trade-off between
  what should be supported by all boxes (don't make this guaranteed
  size too high) and when the use of TCP becomes useless if this
  guaranteed size is too low. JS put 484 octets in his first draft.
  JPMF changed it to 64k. JS advocated 2k instead. AP, Grand Master
  of Consensus, proposed 8k. Agreed by all parties present; to be
  discussed on the NMRGml. In the meantime, JS puts 8k in his new
  draft.

* ACTION: JS modifies the draft posted by JPMF on May 7 and sends it
  to the NMRGml for review.

2) Compression
   ===========

* Do we want compression only in SNMPv3, or in SNMPv1 and SNMPv2c as
  well? AP and JPMF both mentioned the danger of multiple releases
  branching off. JS argued that since SNMPv3 is not getting deployed
  fast, adding compression to SNMPv1 and SNMPv2c might be a good idea.
  To be discussed on the NMRGml.

* JS: it is important to compress before we encrypt, otherwise we would
  lose any pattern in the data --> poor compression ratio (see IPcomp
  in IPv6).

* We discussed the pros and cons of JS's solutions for compression.

* Solution #1: Compression is a special case of encryption. Problem:
  authentication would become mandatory (because encryption mandates
  authentication in SNMPv3). AP and JPMF: This is a big problem.

* Solution #2: In the SNMPv3 header, the 4th bit of the msgFlags
  (RFC 2572) specifies if compression is used. Name: compressFlag.
  (The 1st bit is authFlag for authentication, the 2nd bit is privFlag
  for encryption, the 3rd bit is reportableFlag for Report PDUs). If
  compressFlag is set, compression is then handled like encryption
  today. Advantage: simple. Drawback: this works only with v3.

* Solution #3: In RFC 2572, a scoped PDU is defined as follows:

       ScopedPDU ::= SEQUENCE {
           contextEngineID  OCTET STRING,
           contextName      OCTET STRING,
           data             ANY -- e.g., PDUs as defined in RFC 1905

  Instead of using only PDUs as defined in RFC 1905, we could define a
  new PDU called compressedPDU. The encoding of this PDU would specify
  to compress the data. We need to put in a MIB a table of all the ANYs
  supported by an entity; this enables a sending entity to find out if
  a receiving entity supports compressedPDU. Advantage: works with v1,
  v2c and v3. Drawback: allows the compression of a little less data
  than solution #2 (the context engine and the context name are not
  compressed with #3).

* There's no clear winner yet. For each solution, we need to study in
  detail the reaction of a normal SNMP agent/manager when it receives
  a compressed SNMP message.

* All solutions require that the compression algorithm (e.g. gzip) be
  specified in a MIB. We need to define this in more detail.

* ACTION: Discuss this on the NMRGml and choose a solution at the
  next NMRG Meeting.

3) SMIng
   =====

* JS: Is NMRG the right forum to discuss SMIng? JPMF=yes. AP=not sure.
  We didn't get enough answers to this question on the NMRGml.

* AP: We should develop a vision of an architecture (service mgmt,
  distributed network mgmt...) together with looking at the more
  detailed things such as SMIng.

* AP: What we miss in SMIv2 is the equivalent of C structures. We have
  only tables. JS: We don't need nested tables, equiv. to structures,
  because nested tables are easy to flatten into a single table (see SQL
  which doesn't support nested tables either).

* JS: We miss the notion of method or function calls with well-defined
  signatures. There are currently many different ways to do the same
  thing via side effects of SET operations. This raises implementation
  cost issues and leads to interoperability problems. How these SMI
  methods or function calls map to underlying management protocols or
  APIs remains to be defined.

* ACTION: JS reposts his question of May 12 to the NMRGml.

4) Long-term aim of NMRG & 5) How should NMRG operate?
   ===================================================

* Starting point: JS is a bit disappointed that we don't get things
  done fast enough. We are very slow to progress. Few people in the
  NMRGml answer his questions. There are many "sleeping partners"
  (do nothing, see what the others do) and not enough active members
  in NMRG.

* We had a long discussion showing that we all expect different
  things from NMRG:

* AP wants to work on a new architecture for Internet mgmt:
  - SLA
  - inter-domain mgmt
  - distributed mgmt
  - not simply network elements
  Preference = architecture. Also interested in design & implem.

* JPMF: Main interest in distributed network mgmt. Manager to manager,
  manager to agent. Define high-level semantics, high-level
  information models. Map to XML.
  Preference = design. Also interested in arch. & implementation.

* JS wants to get real things out, especially prototypes and RFCs.
  His primary interest is to get the initial thing which started the
  NMRG completed (SNMP over TCP, Compression, getsubtree PDU).
  Preference = implementation. Also interested in arch. & design.

* The bad news is:
  - we have different expectations, different poles of interest
  - we are all funded separately to do very different tasks
  - we'll probably never agree to work all on the same thing at the
    same time.

* The good news is:
  - we all want to work together
  - we are very complementary in our interests

* Everyone agrees that this working group has great value, and we all
  like to work together. Still, it may be necessary to adjust our
  mode of operation as all of us are busy with many things, which must
  be performed in parallel with the work for NMRG. We must accept that
  it will not be possible to investigate every research topic that we
  would like. We agreed therefore that we will only start a new topic
  if there is at least one person who takes the lead for that topic,
  and who sends documents to the NMRGml for scrutiny, analysis,
  criticism, feedback... Our commitment as members of NMRG is to make
  the effort to read these documents reasonably fast and spend the
  time to provide valuable feedback. For NMRG to be successful, it is
  important that, once in a while, we set a milestone and produce some
  output: RFC, paper, prototype...

* ACTION: Discuss this on the NMRGml and check if others are happy
  with this change.

6) Next NMRG meetings
   ==================

* It is important that we have meetings several times per year.
  Otherwise the group will dissolve quickly. It is OK that all NMRG
  members don't attend all meetings (money, time schedule...).

* The 3rd NMRG Meeting will take place in Oslo, Norway on July 10,
  just before the 45th IETF Meeting. It will last only 1 day because
  IETF Meetings are already very demanding.

* The 4th NMRG Meeting will take place in Zurich, Switzerland in
  October, together with the DSOM'99 workshop. It will last 2 days.

* ACTION: JS contacts the IETF folks and gets a room in Oslo.

* ACTION: JPMF contacts the organizers of DSOM'99, chooses a date with
  them and gets a room at ETH Zurich.

____________________________________________________________________
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, 07 Jun 1999 19:00:14 +0000
From: Sudhir Pendse <[email-masked]>
Organization: SIMPLESOFT Inc.
To: [email-masked]
Subject: [nmrg] Bulk transfer of mib data - SimpleTimes article
Sender: [email-masked]

Hello,

I recently had a chance to read the "bulk transfer of Mib data"
in the march issue of SimpleTimes and found it most interesting.
I too believe that the existing SNMP mechanisms for bulk data
transfer need improvement.

A few years ago, I had posted an article to the snmp mailing
list (it is attached below) that described a MIB based approach
for enhancing SNMP. Just has the RMON mib has a control table
and a data table, it proposed a BULKDATA mib that had a request
table, and a data table. 

After reading your article, the proposed scheme is very
similar to the hybrid approach suggested by Stewart, except
it does not use ftp, not does it need a proprietary oid
encoding scheme, but it does use "encoded octet strings".

I am sure that the scheme described below needs a lot
of improvements, and infact reading it again, after a few
years, even I can think of a few enhacements.(like using
something like the cbfDefineObjectTable to make it more
generic, or accesing the number of columns in a table more
easily....)

Anyways, I would be most interested in participating in this
research group activities on this topic.  Please let me know
what procedures to follow.

Regards,
-sudhir

-------------------------------------------------------------

A MIB based scheme for bulk retrieval of tabular data is 
described below.  This would be useful for non-gui applications 
to get dumps of entire tables with the least amount of 
inconsistency.

Has anyone already tried such a scheme in their private mibs,
or has such an idea been already discussed ?  Any comments
are most welcome.

The basic idea is to have a dataRequestTable where a manager
entity tells the agent the name of the table that it needs along
with its MTU size, and then the agent acts on this request and 
fills up a dataContentsTable with one or more rows (based on the
manager's MTU size) that is made up of a snapshot of the table 
contents.  

Data compaction is achieved by only returning the common instance 
component, followed by values for each column of the row, instead 
of the usual "entire oid and value" pair.  

A separate dataColumnInfoTable could contain information about 
the agents notion of what columns make up the table.

So for eg:                                Table T1

                                  C1     C2      C3     C4
                                ---------------------------
Row1(Instance component = 5)      5      abc     7      4
Row2(Instance component = 6)      6      pqr     8      9
                              ..
  
Agent will encode the data in the tables as an octet string that
is made up of one or more:

<ASN1 encoding of instance component of row1 prepended with a 0.0>
<ASN1 encoding of value of 1st column in row1>
<ASN1 encoding of value of 2nd column in row1>
<ASN1 encoding of value of 3rd column in row1>
<ASN1 encoding of value of 4th column in row1>

<04 len (06 02 00 05) (02 01 05) (04 03 61 62 63) (02 01 07) (02 01 04)
        (06 02 00 06) (02 01 06) (04 03 70 71 72) (02 01 08) (02 01 09)
        ...>

Once the length of the octet string becomes larger than the MTU 
specified by the manager minus some number like 100, it will create
another row in the dataContents table.  

The 0.0 is prepended to the instance component of the OID, so that
it fits the 40x+y rule for ASN1 encoding of oids. 

If there are "holes" in the table, then a place holder null value
would be used (05 00)

The dataColumnInfoTable will use a similar scheme to list the
oids of the C1,C2,C3 and C4.  Here the oids of the columns (without
their instance component) will be encoded one after the other.

If C1 (index column) is not-accessible, then its value will not be
included, nor will it appear in the dataColumnInfoTable.

Instance component can be made up of columns that are not part
of the table being retrieved.

Enhancements to this scheme could allow the manager to specify
columns instead of the entire table.  A blasphemous concept
would be to not require the agent to sort the instances returned 
in a lexicographic order in the encoding (let the manager do the 
sorting)

The MIB could look like this:

TABULAR-DATA-RETRIEVAL-MIB
==========================

nextAvailableDataRequestId             INTEGER         RO
dataRequestTable
    dataRequestEntry
        dataRequestId                  INTEGER         RW    Index
        dataRequestTableName           OID             RW
        dataRequestMTUSize             INTEGER         RW
        dataRequestRowStatus           RowStatus       RW
 
dataContentsTable              
    dataContentsEntry
        dataContentsRequestId          INTEGER         RO    Index
        dataContentsRowId              INTEGER         RO    Index
        dataContentsEncodedString      OctetString     RO
        dataContentsRowStatus          RowStatus       RW
 
dataColumnInfoTable
    dataColumnInfoEntry
        dataColumnInfoRequestId        INTEGER         RO    Index
        dataColumnInfoRowId            INTEGER         RO    Index
        dataColumnInfoEncodedString    OctetString     RO
        dataColumnInfoRowStatus        RowStatus       RW

Summary:
1) Only returns instance component for all columns in the row and
   their values, rather than full oid name and value pair for
   each column.
2) Since the agent is creating a snapshot of the table and storing
   it, data is more consistent.
3) Uses encoded octetstrings.

                                           - sudhir

-- 
Sudhir Pendse                   Tel:   (650) 965-4515
SIMPLESOFT Inc.                 Fax:   (650) 965-4505
http://www.smplsft.com          Email: [email-masked]