Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id JAA18060 for nmrg-outgoing; Wed, 30 Jun 1999 09:45:41 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id JAA18054; Wed, 30 Jun 1999 09:45:37 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id JAA23135; Wed, 30 Jun 1999 09:45:37 +0200 Date: Wed, 30 Jun 1999 09:45:37 +0200 Message-Id: <199906300745.JAA23135@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: martin-flatin@epfl.ch CC: nmrg@ibr.cs.tu-bs.de, martin-flatin@epfl.ch In-reply-to: <199906291637.SAA04377@icasun1.epfl.ch> (martin-flatin@epfl.ch) Subject: Re: [nmrg] get-subtree already proposed References: <199906291637.SAA04377@icasun1.epfl.ch> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> 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 schoenw@ibr.cs.tu-bs.de 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) Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id SAA03515 for nmrg-outgoing; Tue, 29 Jun 1999 18:37:16 +0200 (MET DST) Received: from icasun1.epfl.ch (root@icasun1.epfl.ch [128.178.151.148]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id SAA03510 for ; Tue, 29 Jun 1999 18:37:15 +0200 (MET DST) Received: from tcomhp31.epfl.ch (tcomhp31.epfl.ch [128.178.151.22]) by icasun1.epfl.ch (8.8.X/EPFL-8.1d for ICA) with ESMTP id SAA04377; Tue, 29 Jun 1999 18:37:14 +0200 (MET DST) Message-Id: <199906291637.SAA04377@icasun1.epfl.ch> X-Mailer: exmh version 2.0.2 2/24/98 From: "J.P. Martin-Flatin" To: nmrg@ibr.cs.tu-bs.de cc: martin-flatin@epfl.ch Reply-To: martin-flatin@epfl.ch Subject: [nmrg] get-subtree already proposed Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 29 Jun 1999 18:37:13 +0200 Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk 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: martin-flatin@epfl.ch Fax: +41-21-693-66-10 Web: http://icawww.epfl.ch/~jpmf/ Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id RAA15573 for nmrg-outgoing; Thu, 24 Jun 1999 17:58:41 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id RAA15566 for ; Thu, 24 Jun 1999 17:58:40 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA03433; Thu, 24 Jun 1999 17:58:40 +0200 Date: Thu, 24 Jun 1999 17:58:40 +0200 Message-Id: <199906241558.RAA03433@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Network Management Research Group Subject: [nmrg] two bug fixes in draft-irtf-nmrg-snmp-tcp-01.txt Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Simon Leinen found the following bug in : 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 schoenw@ibr.cs.tu-bs.de 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) Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id JAA12527 for nmrg-outgoing; Thu, 24 Jun 1999 09:51:30 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id JAA12494; Thu, 24 Jun 1999 09:50:44 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id JAA19006; Thu, 24 Jun 1999 09:50:44 +0200 Date: Thu, 24 Jun 1999 09:50:44 +0200 Message-Id: <199906240750.JAA19006@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: l.deri@tecsiel.it CC: wjhardaker@ucdavis.edu, nmrg@ibr.cs.tu-bs.de In-reply-to: <3771D674.C66E7256@tecsiel.it> (message from Luca Deri on Thu, 24 Jun 1999 08:55:48 +0200) Subject: Re: [nmrg] Wildcarding & Query Processing References: <37032930.F0239944@tecsiel.it> <370332C7.CD9C065C@cs.utwente.nl> <199904061440.QAA13459@henkell.ibr.cs.tu-bs.de> <370B2151.C8A5A9A7@tecsiel.it> <370BA929.164C381C@tecsiel.it> <3771D674.C66E7256@tecsiel.it> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> 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 schoenw@ibr.cs.tu-bs.de 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) Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id IAA10573 for nmrg-outgoing; Thu, 24 Jun 1999 08:57:54 +0200 (MET DST) Received: from solaris.tecsiel.it ([195.103.245.71]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id IAA10565 for ; Thu, 24 Jun 1999 08:57:48 +0200 (MET DST) Received: from tecsiel.it (solaris [193.43.104.7]) by solaris.tecsiel.it (8.9.1b+Sun/8.9.1) with ESMTP id IAA22681; Thu, 24 Jun 1999 08:55:48 +0200 (MET DST) Message-ID: <3771D674.C66E7256@tecsiel.it> Date: Thu, 24 Jun 1999 08:55:48 +0200 From: Luca Deri Reply-To: l.deri@tecsiel.it Organization: Finsiel S.p.A. X-Mailer: Mozilla 4.51 [en] (X11; I; SunOS 5.7 i86pc) X-Accept-Language: en MIME-Version: 1.0 To: Wes Hardaker CC: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] Wildcarding & Query Processing References: <37032930.F0239944@tecsiel.it> <370332C7.CD9C065C@cs.utwente.nl> <199904061440.QAA13459@henkell.ibr.cs.tu-bs.de> <370B2151.C8A5A9A7@tecsiel.it> <370BA929.164C381C@tecsiel.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk 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: l.deri@tecsiel.it WWW: http://www.tlcpi.finsiel.it/~deri/ Software is about stuff, about getting hands dirty - Jim Coplien Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id KAA03895 for nmrg-outgoing; Tue, 22 Jun 1999 10:58:34 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id KAA03869; Tue, 22 Jun 1999 10:58:12 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id KAA28925; Tue, 22 Jun 1999 10:58:12 +0200 Date: Tue, 22 Jun 1999 10:58:12 +0200 Message-Id: <199906220858.KAA28925@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: internet-drafts@ietf.org CC: Network Management Research Group Subject: [nmrg] draft-irtf-nmrg-snmp-compression-00.txt Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Cynthia, please post the attached document as Internet Draft . 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 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 . 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: schoenw@ibr.cs.tu-bs.de 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] Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id KAA02923 for nmrg-outgoing; Tue, 22 Jun 1999 10:34:30 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id KAA02917; Tue, 22 Jun 1999 10:34:25 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id KAA27763; Tue, 22 Jun 1999 10:34:25 +0200 Date: Tue, 22 Jun 1999 10:34:25 +0200 Message-Id: <199906220834.KAA27763@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: l.deri@tecsiel.it CC: nmrg@ibr.cs.tu-bs.de In-reply-to: <376F2CFC.1A7AE8FE@tecsiel.it> (message from Luca Deri on Tue, 22 Jun 1999 08:28:12 +0200) Subject: Re: [nmrg] [Fwd: Authorship, CRC Press] References: <376F2CFC.1A7AE8FE@tecsiel.it> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> 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 schoenw@ibr.cs.tu-bs.de 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) Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id IAA27990 for nmrg-outgoing; Tue, 22 Jun 1999 08:29:57 +0200 (MET DST) Received: from solaris.tecsiel.it ([195.103.245.71]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id IAA27985 for ; Tue, 22 Jun 1999 08:29:55 +0200 (MET DST) Received: from tecsiel.it (solaris [193.43.104.7]) by solaris.tecsiel.it (8.9.1b+Sun/8.9.1) with ESMTP id IAA17475 for ; Tue, 22 Jun 1999 08:28:12 +0200 (MET DST) Message-ID: <376F2CFC.1A7AE8FE@tecsiel.it> Date: Tue, 22 Jun 1999 08:28:12 +0200 From: Luca Deri Reply-To: l.deri@tecsiel.it Organization: Finsiel S.p.A. X-Mailer: Mozilla 4.51 [en] (X11; I; SunOS 5.7 i86pc) X-Accept-Language: en MIME-Version: 1.0 To: NMRG Mailing List Subject: [nmrg] [Fwd: Authorship, CRC Press] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk 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 sabazamir@aol.com. 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: l.deri@tecsiel.it WWW: http://www.tlcpi.finsiel.it/~deri/ Software is about stuff, about getting hands dirty - Jim Coplien Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id RAA04523 for nmrg-outgoing; Fri, 18 Jun 1999 17:44:36 +0200 (MET DST) Received: from rondel.ibr.cs.tu-bs.de (rondel [134.169.34.194]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id RAA04518 for ; Fri, 18 Jun 1999 17:44:35 +0200 (MET DST) Received: from schoenw@localhost by rondel.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA04914; Fri, 18 Jun 1999 17:44:35 +0200 Date: Fri, 18 Jun 1999 17:44:35 +0200 Message-Id: <199906181544.RAA04914@rondel.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de Subject: [nmrg] meeting details for Oslo Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk 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 . Juergen -- Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de 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) Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id PAA21051 for nmrg-outgoing; Thu, 17 Jun 1999 15:51:20 +0200 (MET DST) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id PAA21043; Thu, 17 Jun 1999 15:51:16 +0200 (MET DST) Received: from alden (ALDEN.maxware.no [10.128.1.34]) by dokka.maxware.no (8.8.7/8.8.7) with ESMTP id PAA04334; Thu, 17 Jun 1999 15:51:14 +0200 Message-Id: <4.2.0.56.19990617153907.0245c990@dokka.maxware.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta) Date: Thu, 17 Jun 1999 15:49:27 +0200 To: Juergen Schoenwaelder From: Harald Tveit Alvestrand Subject: Re: Closing connections (Re: [nmrg] draft-irtf-nmrg-snmp-tcp-01.txt (preview)) Cc: nmrg@ibr.cs.tu-bs.de In-Reply-To: <199906161515.RAA23654@henkell.ibr.cs.tu-bs.de> References: <4.2.0.56.19990615162646.00bce9d0@dokka.maxware.no> <4.2.0.56.19990615162646.00bce9d0@dokka.maxware.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk 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 Harald.Alvestrand@maxware.no Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id RAA25072 for nmrg-outgoing; Wed, 16 Jun 1999 17:15:54 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id RAA25051; Wed, 16 Jun 1999 17:15:40 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA23654; Wed, 16 Jun 1999 17:15:40 +0200 Date: Wed, 16 Jun 1999 17:15:40 +0200 Message-Id: <199906161515.RAA23654@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Harald@Alvestrand.no CC: nmrg@ibr.cs.tu-bs.de In-reply-to: <4.2.0.56.19990615162646.00bce9d0@dokka.maxware.no> (message from Harald Tveit Alvestrand on Tue, 15 Jun 1999 16:42:54 +0200) Subject: Re: Closing connections (Re: [nmrg] draft-irtf-nmrg-snmp-tcp-01.txt (preview)) References: <4.2.0.56.19990615162646.00bce9d0@dokka.maxware.no> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> 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 schoenw@ibr.cs.tu-bs.de 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) Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id SAA29994 for nmrg-outgoing; Tue, 15 Jun 1999 18:23:29 +0200 (MET DST) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id SAA29985; Tue, 15 Jun 1999 18:23:23 +0200 (MET DST) Received: from alden ([10.128.167.143]) by dokka.maxware.no (8.8.7/8.8.7) with ESMTP id SAA30123; Tue, 15 Jun 1999 18:23:13 +0200 Message-Id: <4.2.0.56.19990615162646.00bce9d0@dokka.maxware.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta) Date: Tue, 15 Jun 1999 16:42:54 +0200 To: Juergen Schoenwaelder , Network Management Research Group From: Harald Tveit Alvestrand Subject: Closing connections (Re: [nmrg] draft-irtf-nmrg-snmp-tcp-01.txt (preview)) In-Reply-To: <199906111513.RAA29887@henkell.ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk 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 Harald.Alvestrand@maxware.no Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id PAA17964 for nmrg-outgoing; Mon, 14 Jun 1999 15:55:04 +0200 (MET DST) Received: from icasun1.epfl.ch (root@icasun1.epfl.ch [128.178.151.148]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id PAA17959 for ; Mon, 14 Jun 1999 15:55:03 +0200 (MET DST) Received: from tcomhp31.epfl.ch (tcomhp31.epfl.ch [128.178.151.22]) by icasun1.epfl.ch (8.8.X/EPFL-8.1d for ICA) with ESMTP id PAA19057; Mon, 14 Jun 1999 15:55:01 +0200 (MET DST) Message-Id: <199906141355.PAA19057@icasun1.epfl.ch> X-Mailer: exmh version 2.0.2 2/24/98 From: "J.P. Martin-Flatin" To: nmrg@ibr.cs.tu-bs.de Cc: martin-flatin@epfl.ch Reply-To: martin-flatin@epfl.ch Subject: Re: [nmrg] meeting in Oslo In-reply-to: Your message of "Fri, 11 Jun 1999 17:21:23 METDST." <199906111521.RAA00138@henkell.ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 14 Jun 1999 15:55:01 +0200 Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk 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: martin-flatin@epfl.ch Fax: +41-21-693-66-10 Web: http://icawww.epfl.ch/~jpmf/ Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id NAA12032 for nmrg-outgoing; Mon, 14 Jun 1999 13:43:40 +0200 (MET DST) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id NAA12022; Mon, 14 Jun 1999 13:43:35 +0200 (MET DST) Received: from ctit.utwente.nl (utip064.cs.utwente.nl [130.89.16.21]) by utrhcs.cs.utwente.nl (8.9.1/8.9.1) with ESMTP id NAA15976; Mon, 14 Jun 1999 13:43:31 +0200 (MET DST) Message-ID: <3764EAC4.1734F848@ctit.utwente.nl> Date: Mon, 14 Jun 1999 13:43:00 +0200 From: Aiko Pras X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Schoenwaelder CC: Network Management Research Group , Ron Sprenkels , Bert-Jan van Beijnum , Henk Eertink , Aiko Pras Subject: Re: [nmrg] meeting in Oslo References: <199906111521.RAA00138@henkell.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk 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 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id TAA09855 for nmrg-outgoing; Fri, 11 Jun 1999 19:04:07 +0200 (MET DST) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id TAA09850 for ; Fri, 11 Jun 1999 19:04:03 +0200 (MET DST) Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.117.200.23]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA192002; Fri, 11 Jun 1999 13:03:40 -0400 Received: from BLDVMA.boulder.ibm.com (bldvma.boulder.ibm.com [9.99.64.30]) by northrelay03.pok.ibm.com (8.8.8m2/NCO v2.01) with SMTP id NAA218572; Fri, 11 Jun 1999 13:03:43 -0400 Message-Id: <199906111703.NAA218572@northrelay03.pok.ibm.com> Received: from UITVM1 by BLDVMA.boulder.ibm.com (IBM VM SMTP V2R4) with BSMTP id 6848; Fri, 11 Jun 99 11:03:47 MDT Date: Fri, 11 Jun 99 19:01:24 DST From: "Bert Wijnen" To: nmrg@ibr.cs.tu-bs.de cc: dthaler@dthaler.microsoft.com Subject: [nmrg] meeting in Oslo Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk 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 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id RAA06173 for nmrg-outgoing; Fri, 11 Jun 1999 17:31:15 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id RAA06168; Fri, 11 Jun 1999 17:31:05 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA00389; Fri, 11 Jun 1999 17:31:05 +0200 Date: Fri, 11 Jun 1999 17:31:05 +0200 Message-Id: <199906111531.RAA00389@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: spendse@smplsft.com CC: nmrg@ibr.cs.tu-bs.de In-reply-to: <199906081244.OAA11832@henkell.ibr.cs.tu-bs.de> (message from Sudhir Pendse on Mon, 07 Jun 1999 19:00:14 +0000) Subject: Re: [nmrg] Bulk transfer of mib data - SimpleTimes article References: <199906081244.OAA11832@henkell.ibr.cs.tu-bs.de> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> 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 schoenw@ibr.cs.tu-bs.de 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) Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id RAA06144 for nmrg-outgoing; Fri, 11 Jun 1999 17:30:47 +0200 (MET DST) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id RAA06136; Fri, 11 Jun 1999 17:30:45 +0200 (MET DST) Received: from myrtilos.cs.utwente.nl (myrtilos.cs.utwente.nl [130.89.16.9]) by utrhcs.cs.utwente.nl (8.9.1/8.9.1) with SMTP id RAA15389; Fri, 11 Jun 1999 17:30:42 +0200 (MET DST) Received: from cs.utwente.nl by myrtilos.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id RAA10888; Fri, 11 Jun 1999 17:30:42 +0200 Message-ID: <37612B9E.76EBAFE1@cs.utwente.nl> Date: Fri, 11 Jun 1999 17:30:38 +0200 From: Ron Sprenkels Organization: University of Twente X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Schoenwaelder CC: Network Management Research Group Subject: Re: [nmrg] meeting in Oslo References: <199906111521.RAA00138@henkell.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk 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 sprenkel@cs.utwente.nl 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) Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id RAA05986 for nmrg-outgoing; Fri, 11 Jun 1999 17:24:30 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id RAA05572; Fri, 11 Jun 1999 17:21:24 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA00138; Fri, 11 Jun 1999 17:21:23 +0200 Date: Fri, 11 Jun 1999 17:21:23 +0200 Message-Id: <199906111521.RAA00138@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Network Management Research Group CC: dthaler@dthaler.microsoft.com Subject: [nmrg] meeting in Oslo Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk 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 schoenw@ibr.cs.tu-bs.de 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) Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id RAA05343 for nmrg-outgoing; Fri, 11 Jun 1999 17:13:23 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id RAA05335; Fri, 11 Jun 1999 17:13:22 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA29887; Fri, 11 Jun 1999 17:13:22 +0200 Date: Fri, 11 Jun 1999 17:13:22 +0200 Message-Id: <199906111513.RAA29887@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Network Management Research Group Subject: [nmrg] draft-irtf-nmrg-snmp-tcp-01.txt (preview) Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk 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 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, . 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: schoenw@ibr.cs.tu-bs.de" 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: schoenw@ibr.cs.tu-bs.de 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] Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id SAA08997 for nmrg-outgoing; Thu, 10 Jun 1999 18:22:50 +0200 (MET DST) Received: from icasun1.epfl.ch (root@icasun1.epfl.ch [128.178.151.148]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id SAA08992 for ; Thu, 10 Jun 1999 18:22:48 +0200 (MET DST) Received: from tcomhp31.epfl.ch (tcomhp31.epfl.ch [128.178.151.22]) by icasun1.epfl.ch (8.8.X/EPFL-8.1d for ICA) with ESMTP id SAA25366; Thu, 10 Jun 1999 18:22:46 +0200 (MET DST) Message-Id: <199906101622.SAA25366@icasun1.epfl.ch> X-Mailer: exmh version 2.0.2 2/24/98 From: "J.P. Martin-Flatin" To: nmrg@ibr.cs.tu-bs.de cc: martin-flatin@epfl.ch Reply-To: martin-flatin@epfl.ch Subject: [nmrg] Minutes of the 2nd NMRG meeting Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 10 Jun 1999 18:22:46 +0200 Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk 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: martin-flatin@epfl.ch Fax: +41-21-693-66-10 Web: http://icawww.epfl.ch/~jpmf/ Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id OAA00988 for nmrg-outgoing; Tue, 8 Jun 1999 14:44:15 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id OAA00983 for ; Tue, 8 Jun 1999 14:44:14 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id OAA11832; Tue, 8 Jun 1999 14:44:14 +0200 Message-Id: <199906081244.OAA11832@henkell.ibr.cs.tu-bs.de> Date: Mon, 07 Jun 1999 19:00:14 +0000 From: Sudhir Pendse Organization: SIMPLESOFT Inc. X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: nmrg@ibr.cs.tu-bs.de Subject: [nmrg] Bulk transfer of mib data - SimpleTimes article Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk 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: <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: spendse@smplsft.com