Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id OAA23623 for nmrg-outgoing; Wed, 19 May 1999 14:18: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 OAA23618 for ; Wed, 19 May 1999 14:18: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 OAA21699; Wed, 19 May 1999 14:18:01 +0200 (MET DST) Message-Id: <199905191218.OAA21699@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] meetings In-reply-to: Your message of "Wed, 19 May 1999 13:35:47 METDST." <199905191135.NAA04540@henkell.ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 May 1999 14:18:00 +0200 Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk On Wed, 19 May 1999 13:35:47 +0200, Juergen Schoenwaelder wrote: > > I will meet Aiko on Sunday morning at 10:00 am at the Boston Park > Plaza Hotel. Its fine with me if you want to join us. OK 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 NAA21809 for nmrg-outgoing; Wed, 19 May 1999 13:35:53 +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 NAA21804; Wed, 19 May 1999 13:35:48 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id NAA04540; Wed, 19 May 1999 13:35:47 +0200 Date: Wed, 19 May 1999 13:35:47 +0200 Message-Id: <199905191135.NAA04540@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: <199905191133.NAA21460@icasun1.epfl.ch> (martin-flatin@epfl.ch) Subject: Re: [nmrg] meetings References: <199905191133.NAA21460@icasun1.epfl.ch> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> J P Martin-Flatin writes: J> It appears that we will be the only NMRG members present at J> IM'99. When and where shall we meet? I will take the plane tomorrow J> morning, so we need to decide fast. If you read this message after J> 7pm today, please leave a message for me at the reception of the J> Boston Park Plaza Hotel. What about having lunch together on J> Sunday 23? I will meet Aiko on Sunday morning at 10:00 am at the Boston Park Plaza Hotel. Its fine with me if you want to join us. 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 NAA21760 for nmrg-outgoing; Wed, 19 May 1999 13:33:11 +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 NAA21755 for ; Wed, 19 May 1999 13:33:09 +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 NAA21460; Wed, 19 May 1999 13:33:08 +0200 (MET DST) Message-Id: <199905191133.NAA21460@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] meetings In-reply-to: Your message of "Sat, 01 May 1999 13:09:43 METDST." <372AE0F7.9F30A28B@ctit.utwente.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 May 1999 13:33:07 +0200 Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk On Sat, 01 May 1999 13:09:43 +0200, Aiko Pras wrote: > > I'll be at the IM'99. Although I have not yet arranged my flight, > most meeting times will be possible for me. Who else is going to > IM'99? And in what hotels are you staying? I would like to stay > in the same hotel, so it would be easier to meet. Juergen and Aiko, It appears that we will be the only NMRG members present at IM'99. When and where shall we meet? I will take the plane tomorrow morning, so we need to decide fast. If you read this message after 7pm today, please leave a message for me at the reception of the Boston Park Plaza Hotel. What about having lunch together on Sunday 23? 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 RAA10093 for nmrg-outgoing; Tue, 18 May 1999 17:27:18 +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 RAA10088 for ; Tue, 18 May 1999 17:27:17 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA04491; Tue, 18 May 1999 17:27:17 +0200 Date: Tue, 18 May 1999 17:27:17 +0200 Message-Id: <199905181527.RAA04491@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Network Management Research Group Subject: [nmrg] [brian@hursley.ibm.com: New IRTF Chair in September] Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk For your information. Juergen ------- Start of forwarded message ------- Date: Tue, 18 May 1999 15:46:16 +0100 From: Brian E Carpenter Organization: IBM Internet Division To: Karen Sollins , Bob Braden , Susan Hares , Allison Mankin , Cecilia Preston , Clifford Lynch , Ran Canetti , Dan Harkins , Mark Handley , Sid Nag , Juergen Schoenwaelder , Harald Tveit Alvestrand , IAB , Rob Austein , Geoff Huston , Ran Atkinson CC: IESG , IAB Subject: New IRTF Chair in September To: all IRTF members, and other interested parties [Research Group chairs, please forward to your groups. Steve Coya, please forward to ietf-announce.] During March, the IAB called for nominations for the position of Chair of the Internet Research Task Force (IRTF), since Abel Weinrib expressed his desire to step down. We received twenty excellent nominations by the closing date of April 15, and had considerable diffculty choosing among those nominees willing to serve. After careful discussion, the IAB is pleased to announce the appointment of Erik Huizer as Chair of the IRTF for two years starting in September 1999. A short biography is attached below. I would like to take this opportunity to thank Abel Weinrib for his years of service, to thank the unsuccessful candidates for their willingness to serve, and to wish Erik every success. Brian Carpenter IAB Chair ========== Erik Huizer is the Managing Director of the SURFnet ExpertiseCentrum bv, a company based in the Netherlands that does network development, design, planning, support, training and consultancy for an international customer base. >From 1988 till 1994 he worked as a Technical Manager at SURFnet bv, the company that operates the Academic and Research network in The Netherlands. Huizer has extensive experience with Internet technology. He has been a member of the RARE (now Terena) Technical Committee from 1991-1994. He was an Area Director for the Applications area of the Internet Engineering Task Force from 1990-1995. He was a member of the Internet Architecture Board from 1995-1999. Huizer is currently involved with the GigaPort project (http://www.gigaport.nl/), the Dutch national project for the Next Generation Internet. Huizer received his Ph. D. degree in Science and Technology from Delft University of Technology, The Netherlands, in 1987. ============ ------- End of forwarded message ------- Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id RAA12500 for nmrg-outgoing; Fri, 14 May 1999 17:36:48 +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 RAA12495 for ; Fri, 14 May 1999 17:36:46 +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 RAA28817; Fri, 14 May 1999 17:36:45 +0200 (MET DST) Message-Id: <199905141536.RAA28817@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] SMIng - another work item for the NMRG? In-reply-to: Your message of "Wed, 12 May 1999 18:47:20 METDST." <199905121647.SAA08040@henkell.ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 May 1999 17:36:44 +0200 Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk On Wed, 12 May 1999 18:47:20 +0200, Juergen Schoenwaelder wrote: > > Here is a proposal to add another work item to the NMRG. This is a > poll for opinions from the NMRG members. > > [...] > > The proposal is to continue the development of SMIng under the > umbrella of the NMRG. This means that the specification of SMIng will > be published as an internet draft of the NMRG rather than an > individual submission and that we will use some of the bandwidth of > the NMRG mailing list for further discussions on SMIng. I agree with your proposal. I think it's a good idea. Your student did an excellent work, especially in laying out the outcome of his M.S. thesis at: http://www.ibr.cs.tu-bs.de/~strauss/sming/ Note that the link behind IRTF-NMRG-SMING-TYPE is currently dangling. 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 SAA02855 for nmrg-outgoing; Wed, 12 May 1999 18:47:22 +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 SAA02842; Wed, 12 May 1999 18:47:20 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id SAA08040; Wed, 12 May 1999 18:47:20 +0200 Date: Wed, 12 May 1999 18:47:20 +0200 Message-Id: <199905121647.SAA08040@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Network Management Research Group CC: strauss@ibr.cs.tu-bs.de Subject: [nmrg] SMIng - another work item for the NMRG? Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Here is a proposal to add another work item to the NMRG. This is a poll for opinions from the NMRG members. Below is the description of the proposal. Please share your comments. Juergen Background: As you all know, SMIv2 just recently got published as Internet Standard 58 and I guess that the IETF is highly interested to keep this standard stable for a while. Nevertheless, there are known problems and shortcomings with SMIv2 which could not be fixed in the revision process. Hence, we started to ask ourself how the next generation of the SMI could look like. This was the birth of the SMIng project. The goal was to stay compatible to the SMIv2 and to fix at the same time as many of the known problems without turning SMIng into a kitchen sink. This means that we have made many trade-off decisions during the design of SMIng. SMIng is meant to be an evolutionary rather than a revolutionary next step. Status: The SMIng project reached a state where we have a first complete specification for SMIng as well as an implementation of MIB parsers and converters between SMIv2 and SMIng. Frank Strauss, one of our masters student, did most of the work as part of his final project assignement. The implementation itself comes as an embeddable C library for accessing MIB definitions and it will be freely available. The implementation also supports SMIv1/SMIv2 for which Frank developed a lex/yacc definition from scratch. (Frank did this work during the SMIv2 revision process and he reported several problems back to the SMI design team.) You can find more background material as well as the current SMIng specification on Frank's Web page at . Proposal: The proposal is to continue the development of SMIng under the umbrella of the NMRG. This means that the specification of SMIng will be published as an internet draft of the NMRG rather than an individual submission and that we will use some of the bandwidth of the NMRG mailing list for further discussions on SMIng. -- 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 SAA27640 for nmrg-outgoing; Fri, 7 May 1999 18:25:30 +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 SAA27635 for ; Fri, 7 May 1999 18:25:28 +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 SAA23637; Fri, 7 May 1999 18:25:27 +0200 (MET DST) Message-Id: <199905071625.SAA23637@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] draft-irtf-nmrg-snmp-tcp-00.txt In-reply-to: Your message of "Tue, 20 Apr 1999 11:44:16 METDST." <199904200944.LAA08885@henkell.ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_-21417432320" Date: Fri, 07 May 1999 18:25:26 +0200 Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk This is a multipart MIME message. --==_Exmh_-21417432320 Content-Type: text/plain; charset=us-ascii On Tue, 20 Apr 1999 11:44:16 +0200, Juergen Schoenwaelder wrote: > > (I did not add definitions for IPv6 since we do not have a resolution > for SNMP over UDP/IPv6 yet and I do not consider this important for > our current goal.) Agreed > Below is the revised document for review. Sorry I took so long to review it. You will find in attachment: 1) the new draft that I propose 2) a Unix diff between the old and the new draft The main changes are: 1) I disagree with section 3.3: we should not restrict the use of TCP here, we should only recommend some possible uses. Tomorrow, a good reason might crop up to use it for something else, thereby rendering our RFC obsolete. 2) I added a new paragraph to section 3.3 describing what I believe to be another valid use of TCP instead of UDP. Comments are welcome. The other changes are minor. I tried to be more systematic in the use of MUST, SHOULD, CAN, etc. I also tried to be consistent in the number of white spaces after a period, hence my changes in the IETF sections. 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/ --==_Exmh_-21417432320 Content-Type: text/plain ; name="draft-tcp.new"; charset=us-ascii Content-Description: draft-tcp.new Content-Disposition: attachment; filename="draft-tcp.new" Network Working Group J. Schoenwaelder, Editor Internet-Draft TU Braunschweig Expires November 1999 7 May 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 April 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 April 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 "9904201100Z" ORGANIZATION "IRTF Network Management Research Group" CONTACT-INFO "Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany Tel: +49 531 391-3283 E-mail: 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/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" STATUS current J. Schoenwaelder [Page 3] Internet-Draft SNMP over TCP Transport Mapping April 1999 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 TCP connection (persistent 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 acting in an agent role to listen on TCP port 161 for incoming connections, in addition to already listening on UDP port 161. It is also RECOMMENDED that notification sinks be configured to listen on TCP port 162, in addition to already listening on UDP port 162. J. Schoenwaelder [Page 4] Internet-Draft SNMP over TCP Transport Mapping April 1999 When an SNMP entity uses the TCP transport mapping, it MUST be capable of accepting messages that are at least 65495 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 SHOULD primarily be used when the large size of the data transferred would cause a large latency if UDP connections were used instead, due to the small size of UDP packets and the increased number of interactions. TCP connections MAY also replace UDP connections when the SNMP entity acting in a manager role does not support retransmissions over UDP at the application level. In this case, the automatic retries of TCP give a better chance to management data to be successfully transferred. All SNMP entities (whether in an agent role or manager role) CAN close the 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. 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 April 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, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, Harvard University, March 1997. [3] Sprenkels, R., and Martin-Flatin, J.P., "Bulk Transfers of MIB Data", The Simple Times, Vol. 7, No. 1, pp. 1-7, March 1999. 6. Editor's Address Juergen Schoenwaelder Email: schoenw@ibr.cs.tu-bs.de TU Braunschweig Tel: +49 531 391-3283 Bueltenweg 74/75 38106 Braunschweig Germany J. Schoenwaelder [Page 6] Internet-Draft SNMP over TCP Transport Mapping April 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] --==_Exmh_-21417432320 Content-Type: text/plain ; name="draft-tcp.diff" Content-Description: draft-tcp.diff Content-Disposition: attachment; filename="draft-tcp.diff" *** draft-tcp.old Fri May 7 13:36:59 1999 --- draft-tcp.new Fri May 7 17:57:39 1999 *************** *** 1,6 **** Network Working Group J. Schoenwaelder, Editor Internet-Draft TU Braunschweig ! Expires October 1999 20 April 1999 SNMP over TCP Transport Mapping --- 1,6 ---- Network Working Group J. Schoenwaelder, Editor Internet-Draft TU Braunschweig ! Expires November 1999 7 May 1999 SNMP over TCP Transport Mapping *************** *** 10,23 **** 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 --- 10,23 ---- 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 *************** *** 27,37 **** 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 --- 27,37 ---- 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 *************** *** 49,54 **** --- 49,57 ---- + + + J. Schoenwaelder [Page 1] Internet-Draft SNMP over TCP Transport Mapping April 1999 *************** *** 60,66 **** 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 --- 63,69 ---- 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 *************** *** 157,167 **** ::= { nmrgSnmpDomains 6 } -- matches first unused value -- below snmpDomains ! SnmpTCPAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d.1d.1d.1d/2d" STATUS current - J. Schoenwaelder [Page 3] Internet-Draft SNMP over TCP Transport Mapping April 1999 --- 160,169 ---- ::= { nmrgSnmpDomains 6 } -- matches first unused value -- below snmpDomains ! snmpTCPAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d.1d.1d.1d/2d" STATUS current J. Schoenwaelder [Page 3] Internet-Draft SNMP over TCP Transport Mapping April 1999 *************** *** 175,180 **** --- 177,183 ---- 5-6 TCP-port network-byte order " SYNTAX OCTET STRING (SIZE (6)) + END *************** *** 182,222 **** SNMP over TCP is an optional transport mapping. Implementors are encouraged to support SNMP over TCP whenever possible because this ! enables applications to use more efficient bulk MIB data transfers. ! Note, the originator of a request/response transaction chooses the ! transport protocol for the whole 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, since TCP costs in terms of resource usage are higher than ! UDP costs, applications using SNMP over TCP may choose to switch back ! to UDP (i.e. by refusing new TCP connections) whenever necessary ! (i.e. 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 send over a TCP connection. ! Note, it is possible to exchange multiple SNMP request/response pairs ! over a single TCP connection. The length field in the BER encoded ! SNMP message is used to separate multiple requests send over a single ! TCP connection. ! 3.2. Well-known Values ! It is suggested that administrators configure their SNMP entities acting in an agent role to listen on TCP port 161 for incoming ! connections. Further, it is suggested that notification sinks be ! configured to listen on TCP port 162. ! ! When an SNMP entity uses this transport mapping, it must be capable ! of accepting messages that are at least 484 octets in size. J. Schoenwaelder [Page 4] --- 185,224 ---- 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 TCP connection (persistent 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 acting in an agent role to listen on TCP port 161 for incoming ! connections, in addition to already listening on UDP port 161. It is ! also RECOMMENDED that notification sinks be configured to listen on ! TCP port 162, in addition to already listening on UDP port 162. J. Schoenwaelder [Page 4] *************** *** 224,271 **** Internet-Draft SNMP over TCP Transport Mapping April 1999 Implementation of larger values is encouraged whenever possible. 3.3. Connection Management The use of TCP connections introduces costs. Connection establishment ! and shutdown causes additional traffic on the wire. Further, maintaining open connections binds resources in the network layer of the underlying operating system. ! TCP connections should therefore only be used when the size of the ! data transferred would otherwise cause large latencies due to small ! UDP packet sizes and an increased number of interactions. ! ! Both, an SNMP entity in the agent role and an SNMP entity in the ! manager role, are allowed to close the connections at any point in ! time. This ensures that SNMP entities can control their resource ! usage and shutdown TCP connections that are not used. Note, SNMP ! engines are not expected to process any outstanding requests if the ! underlying TCP connection has been closed. A no response error ! condition SHOULD be signalled for outstanding requests for command ! generator applications if the TCP connection is closed. 4. Acknowledgments The definitions in this memo are inspired by definitions found in RFC ! 1906 [1]. This document is the result 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 ! ! ! ! ! ! ! ! ! --- 226,273 ---- Internet-Draft SNMP over TCP Transport Mapping April 1999 + When an SNMP entity uses the TCP transport mapping, it MUST be + capable of accepting messages that are at least 65495 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 SHOULD primarily be used when the large size of the ! data transferred would cause a large latency if UDP connections were ! used instead, due to the small size of UDP packets and the increased ! number of interactions. ! ! TCP connections MAY also replace UDP connections when the SNMP entity ! acting in a manager role does not support retransmissions over UDP ! at the application level. In this case, the automatic retries of TCP ! give a better chance to management data to be successfully ! transferred. ! ! All SNMP entities (whether in an agent role or manager role) CAN ! close the 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. 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. *************** *** 291,296 **** --- 293,301 ---- [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, Harvard University, March 1997. + [3] Sprenkels, R., and Martin-Flatin, J.P., "Bulk Transfers of MIB + Data", The Simple Times, Vol. 7, No. 1, pp. 1-7, March 1999. + 6. Editor's Address *************** *** 328,336 **** - - - J. Schoenwaelder [Page 6] Internet-Draft SNMP over TCP Transport Mapping April 1999 --- 333,338 ---- *************** *** 340,356 **** 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. --- 342,358 ---- 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. --==_Exmh_-21417432320 Content-Type: text/plain; charset=us-ascii ____________________________________________________________________ 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/ --==_Exmh_-21417432320-- Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id SAA26707 for nmrg-outgoing; Fri, 7 May 1999 18:05:05 +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 SAA26702 for ; Fri, 7 May 1999 18:05: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 SAA23529; Fri, 7 May 1999 18:05:02 +0200 (MET DST) Message-Id: <199905071605.SAA23529@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] 484 octets In-reply-to: Your message of "Fri, 07 May 1999 17:55:01 METDST." <199905071555.RAA29872@henkell.ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 May 1999 18:05:01 +0200 Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk On Fri, 7 May 1999 17:55:01 +0200, Juergen Schoenwaelder wrote: > > I believe it is stupid to define a *protocol constant* in a MIB. I don't understand your rationale, but since you're more experienced in SNMP than I am, I'll follow your advice. Jean-Philippe Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id RAA26007 for nmrg-outgoing; Fri, 7 May 1999 17:55:05 +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 RAA25999; Fri, 7 May 1999 17:55:01 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA29872; Fri, 7 May 1999 17:55:01 +0200 Date: Fri, 7 May 1999 17:55:01 +0200 Message-Id: <199905071555.RAA29872@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: <199905071528.RAA23319@icasun1.epfl.ch> (martin-flatin@epfl.ch) Subject: Re: [nmrg] 484 octets References: <199905071528.RAA23319@icasun1.epfl.ch> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> J P Martin-Flatin writes: JP> We're talking about bulk transfers here. If a box is so JP> constrained that it can't have 64k buffers, then it's not a good JP> candidate for TCP-based SNMP transfers, right? Whatever number you pick, it is more or less an arbitrary choice. We can debate endlessly whether 64k is too much or not. This is one of the cases where you can ask N people and you will get at least N different opinions. JP> I picked this example from MIB-II, the first read-only variable JP> that I found (sysDescr). I'm not familiar with SMI syntax, and I'm JP> rushed by something else: could you tell me what I should change? I believe it is stupid to define a *protocol constant* in a MIB. JP> In our case, the value of snmpAnyDomainGuaranteedAcceptedSize JP> (484) is specifiedin RFC 1906, but the other values JP> (snmpUDPGuaranteedAcceptedSize = 1472, JP> snmpCLNSGuaranteedAcceptedSize = 1472, etc.) aren't. Not true. The *protocol constant* is 484. All the other values are just the opinion of a book author. And they definately do not belong into the TCP transport mappings document. JP> In my view, all well-known values ought to be readily retrievable JP> via SNMP. The memory overhead is small for agents, the coding JP> overhead is small for vendors, and it makes it easier for JP> customers to shout at their suppliers if their box doesn't conform JP> to what it announces to do. In a publish-subscribe view of JP> management (which happens to be mine), agents publish what they JP> support. There is a difference whether you publish a *protocol constant* or what is actually implemented in an agent. JP> I'm finishing a new version of the TCP draft that I'll send JP> shortly to the group. Should I put these constants definitions in, JP> or do you think they're a bad idea? I think *protocol constants* for the minimum maximum message size do not belong into the MIB. 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 RAA25033 for nmrg-outgoing; Fri, 7 May 1999 17:28:14 +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 RAA25028 for ; Fri, 7 May 1999 17:28:12 +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 RAA23319; Fri, 7 May 1999 17:28:11 +0200 (MET DST) Message-Id: <199905071528.RAA23319@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] 484 octets In-reply-to: Your message of "Fri, 07 May 1999 16:49:31 METDST." <199905071449.QAA28270@henkell.ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 May 1999 17:28:10 +0200 Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk On Fri, 7 May 1999 16:49:31 +0200, Juergen Schoenwaelder wrote: > > JP> I prefer the second value. I therefore suggest that we modify the > JP> TCP draft and replace 484 octets with 65495 octets in section 3.2. > > You really want to require that every implementation uses 64k buffers? > I personally have no problem with that but I am sure some people from > embedded systems will. We're talking about bulk transfers here. If a box is so constrained that it can't have 64k buffers, then it's not a good candidate for TCP-based SNMP transfers, right? > JP> I also believe that this value should be stored in the MIB and > JP> suggest to add: > > snmpTCPGuaranteedAcceptedSize OBJECT-IDENTITY > SYNTAX DisplayString (SIZE (0..255)) > ACCESS read-only > STATUS current > DESCRIPTION > "All receiving TCP protocol entities are required to accept > messages of at least 65495 octets in length." > ::= { snmpTCPDomain 1 } > > He? This is not legal SMIv2. A managed object which returns a protocol > *constant* is IMHO useless. And why should it be a DisplayString of > size (0..255)? I am confused. I picked this example from MIB-II, the first read-only variable that I found (sysDescr). I'm not familiar with SMI syntax, and I'm rushed by something else: could you tell me what I should change? Regarding the issue of a constant: I don't think it is a good idea to put numeric constants in RFCs under the heading "Well-Known Values" when these RFCs defined MIBs. And I think it is stupid to define them outside these RFCs. In our case, the value of snmpAnyDomainGuaranteedAcceptedSize (484) is specifiedin RFC 1906, but the other values (snmpUDPGuaranteedAcceptedSize = 1472, snmpCLNSGuaranteedAcceptedSize = 1472, etc.) aren't. Grouping all these constants in a single repository is good engineering practice. In my view, all well-known values ought to be readily retrievable via SNMP. The memory overhead is small for agents, the coding overhead is small for vendors, and it makes it easier for customers to shout at their suppliers if their box doesn't conform to what it announces to do. In a publish-subscribe view of management (which happens to be mine), agents publish what they support. I'm finishing a new version of the TCP draft that I'll send shortly to the group. Should I put these constants definitions in, or do you think they're a bad idea? 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 QAA23519 for nmrg-outgoing; Fri, 7 May 1999 16:49:57 +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 QAA23511; Fri, 7 May 1999 16:49:31 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id QAA28270; Fri, 7 May 1999 16:49:31 +0200 Date: Fri, 7 May 1999 16:49:31 +0200 Message-Id: <199905071449.QAA28270@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: martin-flatin@epfl.ch CC: nmrg@ibr.cs.tu-bs.de In-reply-to: <199905071438.QAA23013@icasun1.epfl.ch> (martin-flatin@epfl.ch) Subject: Re: [nmrg] 484 octets References: <199905071438.QAA23013@icasun1.epfl.ch> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> J P Martin-Flatin writes: JP> For snmpTCPDomain, we can be conservative and take 1472 octets, as JP> for snmpUDPDomain, or we can be agressive and pick 64k. More JP> precisely: [...] JP> I prefer the second value. I therefore suggest that we modify the JP> TCP draft and replace 484 octets with 65495 octets in section 3.2. You really want to require that every implementation uses 64k buffers? I personally have no problem with that but I am sure some people from embedded systems will. JP> I also believe that this value should be stored in the MIB and JP> suggest to add: snmpTCPGuaranteedAcceptedSize OBJECT-IDENTITY SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS current DESCRIPTION "All receiving TCP protocol entities are required to accept messages of at least 65495 octets in length." ::= { snmpTCPDomain 1 } He? This is not legal SMIv2. A managed object which returns a protocol *constant* is IMHO useless. And why should it be a DisplayString of size (0..255)? I am confused. 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 QAA22755 for nmrg-outgoing; Fri, 7 May 1999 16:38:25 +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 QAA22746; Fri, 7 May 1999 16:38:23 +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 QAA23013; Fri, 7 May 1999 16:38:22 +0200 (MET DST) Message-Id: <199905071438.QAA23013@icasun1.epfl.ch> X-Mailer: exmh version 2.0.2 2/24/98 From: "J.P. Martin-Flatin" To: Juergen Schoenwaelder Cc: nmrg@ibr.cs.tu-bs.de Reply-To: martin-flatin@epfl.ch Subject: Re: [nmrg] 484 octets In-reply-to: Your message of "Fri, 07 May 1999 15:39:46 METDST." <199905071339.PAA25082@henkell.ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 May 1999 16:38:21 +0200 Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk On Fri, 7 May 1999 15:39:46 +0200, Juergen Schoenwaelder wrote: > > Page ... Thank you > J> 1) Should we remain compliant with an old version of Appletalk (and > J> incidentally RFCs 1906 and 1910) and specify 484? > > J> 2) Should we specify the RFC-1122-compliant value for TCP? > > J> 3) Should we specify the RFC-1122-compliant value for the worst > J> case between TCP and UDP, i.e. UDP? > > We should define what makes sense for TCP. There is IMHO absolutely no > value in using the same minimum size for all transport mappings. Hence, > it does not matter what is defined for snmpUDPDomain. > > Sure, there might be old implementations that only support 484 bytes > in their internal buffers. But I think its reasonable to require > larger buffers while switching to TCP. OK. So we have 2 concepts here: - snmpTCPDomain - snmpAnyDomain For snmpAnyDomain, it makes sense to keep 484 octets. It's historic and it's useless, because the real constraints come from snmpUDPDomain, snmpCLNSDomain, snmpIPXDomain, etc. For snmpTCPDomain, we can be conservative and take 1472 octets, as for snmpUDPDomain, or we can be agressive and pick 64k. More precisely: 1500 (max Ethernet) - 20 (min IP header) - 8 (min UDP header) = 1472 65535 (max IP) - 20 (min IP header) - 20 (min TCP header) = 65495 I prefer the second value. I therefore suggest that we modify the TCP draft and replace 484 octets with 65495 octets in section 3.2. I also believe that this value should be stored in the MIB and suggest to add: snmpTCPGuaranteedAcceptedSize OBJECT-IDENTITY SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS current DESCRIPTION "All receiving TCP protocol entities are required to accept messages of at least 65495 octets in length." ::= { snmpTCPDomain 1 } To be consistent, we should also defined similar values for the existing transport domains. Which calls for the addition of: snmpUDPGuaranteedAcceptedSize OBJECT-IDENTITY SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS current DESCRIPTION "All receiving UDP protocol entities are required to accept messages of at least 1472 octets in length." ::= { snmpUDPDomain 1 } snmpCLNSGuaranteedAcceptedSize OBJECT-IDENTITY SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS current DESCRIPTION "All receiving CLNS protocol entities are required to accept messages of at least 1472 octets in length." ::= { snmpCLNSDomain 1 } snmpCONSGuaranteedAcceptedSize OBJECT-IDENTITY SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS current DESCRIPTION "All receiving CONS protocol entities are required to accept messages of at least 1472 octets in length." ::= { snmpCONSDomain 1 } snmpDDPGuaranteedAcceptedSize OBJECT-IDENTITY SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS current DESCRIPTION "All receiving DDP protocol entities are required to accept messages of at least 484 octets in length." ::= { snmpDDPDomain 1 } snmpIPXGuaranteedAcceptedSize OBJECT-IDENTITY SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS current DESCRIPTION "All receiving IPX protocol entities are required to accept messages of at least 546 octets in length." ::= { snmpIPXDomain 1 } Arguably, we could also specify the lower bound for all transport domains in this MIB, because it is specified in RFC 1906 (although I don't think it is necessary): snmpAnyDomainGuaranteedAcceptedSize OBJECT-IDENTITY SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS current DESCRIPTION "All receiving protocol entities are required to accept messages of at least 484 octets in length, whatever the protocol. This value may be overridden by a value specific to a transport domain." ::= { nmrgSnmpDomains 7 } Jean-Philippe Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id QAA22492 for nmrg-outgoing; Fri, 7 May 1999 16:30:11 +0200 (MET DST) Received: from VNET.IBM.COM (vnet.ibm.com [204.146.168.194]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with SMTP id QAA22487 for ; Fri, 7 May 1999 16:30:09 +0200 (MET DST) Message-Id: <199905071430.QAA22487@mumm.ibr.cs.tu-bs.de> Received: by VNET.IBM.COM (IBM VM SMTP V2R4a) via spool with SMTP id 6692 ; Fri, 07 May 1999 10:29:31 EDT Date: Fri, 7 May 99 16:30:25 DST From: "Bert Wijnen" To: martin-flatin@epfl.ch, nmrg@ibr.cs.tu-bs.de cc: martin-flatin@epfl.ch Subject: [nmrg] 484 octets Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Ref: Your note of Fri, 07 May 1999 15:22:29 +0200 Subject: Re: [nmrg] 484 octets I do not understand what your issue is. The 484 is the minimum maximum value. The maximum maximum value is MUCH larger and that is what we worry about for SNMP over TCP, right? We want to BULK transfer LARGE amounts of MIB data, right? SO what do we care what minimal agents do? we cannot have efficoient communication with them anyway. And they probably will not have large tables.... so....?? Bert Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id PAA20113 for nmrg-outgoing; Fri, 7 May 1999 15:39:52 +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 PAA20103; Fri, 7 May 1999 15:39:47 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id PAA25082; Fri, 7 May 1999 15:39:46 +0200 Date: Fri, 7 May 1999 15:39:46 +0200 Message-Id: <199905071339.PAA25082@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: <199905071322.PAA22543@icasun1.epfl.ch> (martin-flatin@epfl.ch) Subject: Re: [nmrg] 484 octets References: <199905071322.PAA22543@icasun1.epfl.ch> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> J P Martin-Flatin writes: >> Note, Rose mentions other limits in the second revised edition of >> the simple book. J> Page number, please? I can't find it. Page 171 says that 1472 bytes are required for snmpUDPDomain. Page 172 says that 1472 bytes are required for snmpCLNSDomain/snmpCONSDomain. Page 173 says that 484 bytes are required for snmpDDPDomain. Page 174 says that 546 bytes are required for snmpIPXDomain. (BTW, I am also looking forward to see whether the OSI transport mappings will be kept in a revised version of RFC 1906 and how the implementation and deployment report will look like. ;-) J> I'll follow the advice of these two wise men and will refrain J> myself from raising this dangerous issue to the SNMPv3 WG. But what J> about draft-irtf-nmrg-snmp-tcp-00.txt? J> 1) Should we remain compliant with an old version of Appletalk (and J> incidentally RFCs 1906 and 1910) and specify 484? J> 2) Should we specify the RFC-1122-compliant value for TCP? J> 3) Should we specify the RFC-1122-compliant value for the worst J> case between TCP and UDP, i.e. UDP? We should define what makes sense for TCP. There is IMHO absolutely no value in using the same minimum size for all transport mappings. Hence, it does not matter what is defined for snmpUDPDomain. Sure, there might be old implementations that only support 484 bytes in their internal buffers. But I think its reasonable to require larger buffers while switching to TCP. (Even ATM people learned that 53 bytes is a poor match for moving data around. ;-) 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 PAA19084 for nmrg-outgoing; Fri, 7 May 1999 15:22:33 +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 PAA19079 for ; Fri, 7 May 1999 15:22:32 +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 PAA22543; Fri, 7 May 1999 15:22:30 +0200 (MET DST) Message-Id: <199905071322.PAA22543@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] 484 octets In-reply-to: Your message of "Fri, 07 May 1999 13:58:09 MET." <199905071158.NAA15994@mumm.ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 May 1999 15:22:29 +0200 Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk On Fri, 7 May 1999 13:49:03 +0200, Juergen Schoenwaelder wrote: > I am not sure but I think the story was that you can't have messages > larger than 484 bytes on appletalk and they used this constant for all > SNMP transports. Argh... On Fri, 7 May 1999 13:49:03 +0200, Juergen Schoenwaelder wrote: > Note, Rose mentions other limits in the second revised edition of > the simple book. Page number, please? I can't find it. On Fri, 7 May 99 13:58:09 DST, Bert Wijnen wrote: > If it gets changed, then then umpty million SNMPv1 implementations > will not change anyway. RFCs 1906 and 1910 have nothing to do with these umpty million SNMPv1 boxes which follow RFCs 1213, 1157, etc. Old SNMPv1 agents don't care what new RFCs say. It's the job of smart modern managers to comply with old RFCs iff they talk to old agents, and to comply with the latest RFCs iff they talk to brand new boxes. ------------------------ On Fri, 7 May 1999 13:49:03 +0200, Juergen Schoenwaelder wrote: > RFC 1910 is not worth fixing. People will consider such a "fix" a > non-editorial change an debate you to death with regard to RFC 1906. > But it might be fun to bring this up in the SNMPv3 WG. On Fri, 7 May 99 13:58:09 DST, Bert Wijnen wrote: > No... I stroongly recommend to NOT bring it up (but you're free to > do so... we are an OPEN process). I'll follow the advice of these two wise men and will refrain myself from raising this dangerous issue to the SNMPv3 WG. But what about draft-irtf-nmrg-snmp-tcp-00.txt? 1) Should we remain compliant with an old version of Appletalk (and incidentally RFCs 1906 and 1910) and specify 484? This would be backward compatible, Fortran I compatible, COBOL 0.1 compatible, ENIAC compatible, etc. But if RFCs 1906 and 1910 are fixed one day, our document will have to be fixed, too. 2) Should we specify the RFC-1122-compliant value for TCP? 536 = 576 (RFC 1122) - 20 (IP) - 20 (TCP) This would be self-consistent, but would not take into account the UDP reality of SNMP-based management. 3) Should we specify the RFC-1122-compliant value for the worst case between TCP and UDP, i.e. UDP? 548 = 576 (RFC 1122) - 20 (IP) - 8 (UDP) This would be consistent with what the RFCs should be, assuming that the purpose of new documents is to fix older ones. It would not cause a problem if RFCs 1906 & 1910 were updated one day. It would not be compatible with agents conforming to RFCs 1906 and 1910, but that's no problem since people need to change their code anyway to support TCP. 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 NAA16003 for nmrg-outgoing; Fri, 7 May 1999 13:58:08 +0200 (MET DST) Received: from VNET.IBM.COM (vnet.ibm.com [204.146.168.194]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with SMTP id NAA15994; Fri, 7 May 1999 13:58:01 +0200 (MET DST) Message-Id: <199905071158.NAA15994@mumm.ibr.cs.tu-bs.de> Received: by VNET.IBM.COM (IBM VM SMTP V2R4a) via spool with SMTP id 5336 ; Fri, 07 May 1999 07:57:15 EDT Date: Fri, 7 May 99 13:58:09 DST From: "Bert Wijnen" To: schoenw@ibr.cs.tu-bs.de, martin-flatin@epfl.ch cc: nmrg@ibr.cs.tu-bs.de, martin-flatin@epfl.ch Subject: [nmrg] 484 octets Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Ref: Your note of Fri, 7 May 1999 13:49:03 +0200 Subject: Re: [nmrg] 484 octets Juergen writes: > RFC 1910 is not worth fixing. People will consider such a "fix" a > non-editorial change an debate you to death with regard to RFC 1906 > But it might be fun to bring this up in the SNMPv3 WG. > No... I stroongly recommend to NOT bring it up (but you're free to do so... we are an OPEN process). But it will be a waste of time. If it gets changed, then then umpty million SNMPv1 implementations will not change anyway. For SNMPv3, there are other methods for entities to tell what size they support. For the coexistence document we're also proposing a bigger default and again you can specify it in a MIB. Bert (personal opinion) Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id NAA15539 for nmrg-outgoing; Fri, 7 May 1999 13:49:07 +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 NAA15534; Fri, 7 May 1999 13:49:03 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id NAA21496; Fri, 7 May 1999 13:49:03 +0200 Date: Fri, 7 May 1999 13:49:03 +0200 Message-Id: <199905071149.NAA21496@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: <199905071137.NAA21807@icasun1.epfl.ch> (martin-flatin@epfl.ch) Subject: Re: [nmrg] 484 octets References: <199905071137.NAA21807@icasun1.epfl.ch> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> J P Martin-Flatin writes: JP> I have a problem with the minimal value of 484 octets specified JP> in: [...] JP> In other words, all IP hosts *must* accept IP messages that are up JP> to 576 octets in length, and may accept longer messages. Assuming JP> no IP options (worst case), a legal SNMP message can therefore be: JP> 576 - 20 (IP header) - 8 (UDP header) = 548 octets I am not sure but I think the story was that you can't have messages larger than 484 bytes on appletalk and they used this constant for all SNMP transports. Note, Rose mentions other limits in the second revised edition of the simple book. JP> Therefore, as far as I can see, RFC 1906, RFC 1910 and the TCP JP> draft are in contradiction with RFC 1122. Did I overlook JP> something? If you agree, we should propose to modify RFCs 1906 and JP> 1910 (+ change the TCP draft) and make them specify that all SNMP JP> entites must accept messages that are up to 548 octets, not 484 JP> octets. RFC 1910 is not worth fixing. People will consider such a "fix" a non-editorial change an debate you to death with regard to RFC 1906. But it might be fun to bring this up in the SNMPv3 WG. 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 NAA14851 for nmrg-outgoing; Fri, 7 May 1999 13:37:22 +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 NAA14846 for ; Fri, 7 May 1999 13:37:19 +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 NAA21807; Fri, 7 May 1999 13:37:18 +0200 (MET DST) Message-Id: <199905071137.NAA21807@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] 484 octets Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 May 1999 13:37:17 +0200 Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk I have a problem with the minimal value of 484 octets specified in: - sections 3.2, 4.2 and 5.2 of RFC 1906 - sections 2.9 and 5 of RFC 1910 - section 3.2 of draft-irtf-nmrg-snmp-tcp-00.txt RFC 1122 states (about IP reassembly): 3.3.2 Reassembly The IP layer MUST implement reassembly of IP datagrams. We designate the largest datagram size that can be reassembled by EMTU_R ("Effective MTU to receive"); this is sometimes called the "reassembly buffer size". EMTU_R MUST be greater than or equal to 576, SHOULD be either configurable or indefinite, and SHOULD be greater than or equal to the MTU of the connected network(s). In other words, all IP hosts *must* accept IP messages that are up to 576 octets in length, and may accept longer messages. Assuming no IP options (worst case), a legal SNMP message can therefore be: 576 - 20 (IP header) - 8 (UDP header) = 548 octets Therefore, as far as I can see, RFC 1906, RFC 1910 and the TCP draft are in contradiction with RFC 1122. Did I overlook something? If you agree, we should propose to modify RFCs 1906 and 1910 (+ change the TCP draft) and make them specify that all SNMP entites must accept messages that are up to 548 octets, not 484 octets. 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 KAA12764 for nmrg-outgoing; Thu, 6 May 1999 10:05:45 +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 KAA12741; Thu, 6 May 1999 10:05:41 +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 KAA06166; Thu, 6 May 1999 10:05:35 +0200 (MET DST) Received: from cs.utwente.nl by myrtilos.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id KAA29937; Thu, 6 May 1999 10:05:35 +0200 Message-ID: <37314D4D.AD7DAAAE@cs.utwente.nl> Date: Thu, 06 May 1999 10:05:33 +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: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] meetings References: <199904291529.RAA26756@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, > I think its time to talk about face-to-face meetings. I already > mentioned in a previous email the following events: > > May 24-28, 1999 IM '99 Boston > July 12-16, 1999 45. IETF Oslo > October 11-13, 1999 DSOM '99 Z"urich > November 8-12, 1999 46. IETF Washington I won't be at IM99. For the other three options: I don't have a paper at DSOM99, and at this time I don't have prior plans or reasons to attend any IETF meetings. This means that I'll have to discuss this with my boss; I'll let you know asap what comes out of that. 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 SAA27767 for nmrg-outgoing; Tue, 4 May 1999 18:44:22 +0200 (MET DST) Received: from oakdale.ucdavis.edu (oakdale.ucdavis.edu [169.237.210.82]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id SAA27762 for ; Tue, 4 May 1999 18:44:11 +0200 (MET DST) Received: (from hardaker@localhost) by oakdale.ucdavis.edu (8.9.3/8.9.3) id JAA12482; Tue, 4 May 1999 09:44:02 -0700 (PDT) To: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] meetings References: <199905041402.QAA04342@icasun1.epfl.ch> X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 X-url: http://dcas.ucdavis.edu/~hardaker Organization: U.C.Davis, Information Technology - D.C.A.S. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: Wes Hardaker Date: 04 May 1999 09:44:01 -0700 In-Reply-To: "J.P. Martin-Flatin"'s message of "Tue, 04 May 1999 16:02:23 +0200" Message-ID: Lines: 16 User-Agent: Gnus/5.07007 (Pterodactyl Gnus v0.70) XEmacs/21.2(beta13) (Demeter) Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> On Tue, 04 May 1999 16:02:23 +0200, "J.P. Martin-Flatin" said: > On Thu, 29 Apr 1999 17:29:32 +0200, Juergen Schoenwaelder wrote: > > May 24-28, 1999 IM '99 Boston > July 12-16, 1999 45. IETF Oslo > October 11-13, 1999 DSOM '99 Zurich > November 8-12, 1999 46. IETF Washington Unfortunately, the first I can make is probably the November IETF meeting... -- Wes Hardaker Distributed Computing Analysis and Support University of California at Davis Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id QAA22127 for nmrg-outgoing; Tue, 4 May 1999 16:02:30 +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 QAA22119 for ; Tue, 4 May 1999 16:02:26 +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 QAA04342; Tue, 4 May 1999 16:02:24 +0200 (MET DST) Message-Id: <199905041402.QAA04342@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] meetings In-reply-to: Your message of "Thu, 29 Apr 1999 17:29:32 METDST." <199904291529.RAA26756@henkell.ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 May 1999 16:02:23 +0200 Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk On Thu, 29 Apr 1999 17:29:32 +0200, Juergen Schoenwaelder wrote: > > May 24-28, 1999 IM '99 Boston > July 12-16, 1999 45. IETF Oslo > October 11-13, 1999 DSOM '99 Zurich > November 8-12, 1999 46. IETF Washington I will attend IM'99 and DSOM'99. I will not attend any IETF meeting this year. > Regarding IM'99, I will arrive in Boston on Saturday 22 and I will > leave on Friday 28. We can either meet on Sunday or on Friday since I > do not plan to attend any of the Friday tutorials. I will attend two tutorials on Friday, so I'd rather we meet on Sunday. I'll stay at the Boston Park Plaza Hotel. We might find a meeting room there, but I don't know if it'll be free of charge. Alternatively, we could have our meeting in a restaurant. 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 RAA09750 for nmrg-outgoing; Mon, 3 May 1999 17:32:32 +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 RAA09745; Mon, 3 May 1999 17:32:20 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA20055; Mon, 3 May 1999 17:32:20 +0200 Date: Mon, 3 May 1999 17:32:20 +0200 Message-Id: <199905031532.RAA20055@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: l.deri@tecsiel.it CC: nmrg@ibr.cs.tu-bs.de In-reply-to: <3729B323.A36481E2@tecsiel.it> (message from Luca Deri on Fri, 30 Apr 1999 15:41:55 +0200) Subject: Re: [nmrg] meetings References: <199904291529.RAA26756@henkell.ibr.cs.tu-bs.de> <3729B323.A36481E2@tecsiel.it> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> Luca Deri writes: Luca> Concerning IM'99 I have a problem. I should present a poster Luca> session (is about SAMBA+SNMP). Unfortunately when i submitted Luca> the paper I didn't knwo the date of the marriage. Then some Luca> colleagues of mine from Finsiel were supposed to go @ IM'99 but Luca> they recently changed their plans. I'm wondering whether I could Luca> ask some of you to help me. I was thinking so mail you the Luca> poster itself and a few copies of the paper, in order not to Luca> cancel my poster. Does some of you want to gimme this favour? I can help you out. Just send all the material to the following address: Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany I am flying to Boston on Saturday the 22 of May. Please make sure that I receive the material in 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 KAA19979 for nmrg-outgoing; Mon, 3 May 1999 10:54:32 +0200 (MET DST) Received: from VNET.IBM.COM (vnet.ibm.com [204.146.168.194]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with SMTP id KAA19969; Mon, 3 May 1999 10:54:29 +0200 (MET DST) Message-Id: <199905030854.KAA19969@mumm.ibr.cs.tu-bs.de> Received: by VNET.IBM.COM (IBM VM SMTP V2R4a) via spool with SMTP id 6056 ; Mon, 03 May 1999 04:53:51 EDT Date: Mon, 3 May 99 10:54:45 DST From: "Bert Wijnen" To: pras@ctit.utwente.nl, nmrg@ibr.cs.tu-bs.de cc: schoenw@ibr.cs.tu-bs.de Subject: [nmrg] meetings Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Ref: Your note of Sat, 01 May 1999 13:09:43 +0200 Subject: Re: [nmrg] meetings Right now, it seems I will NOT be at IM'99. Sorry, so I can't attend. Bert Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id MAA26724 for nmrg-outgoing; Sat, 1 May 1999 12:04:13 +0200 (MET DST) Received: from dinkel.civ.utwente.nl (dinkel.civ.utwente.nl [130.89.1.2]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with SMTP id MAA26713; Sat, 1 May 1999 12:04:10 +0200 (MET DST) Received: from ctit.utwente.nl (ut197003.inbel.utwente.nl) by dinkel.civ.utwente.nl with SMTP id AA19735 (5.67b/IDA-1.5); Sat, 1 May 1999 12:04:08 +0200 Message-Id: <372AE0F7.9F30A28B@ctit.utwente.nl> Date: Sat, 01 May 1999 13:09:43 +0200 From: Aiko Pras X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en Mime-Version: 1.0 To: Network Management Research Group Cc: Juergen Schoenwaelder Subject: Re: [nmrg] meetings References: <199904291529.RAA26756@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 all I'll be at the IM'99. Although I have not yet arranged my flight, most meeting times will be possible for me. Who else is going to IM'99? And in what hotels are you staying? I would like to stay in the same hotel, so it would be easier to meet. Bye Aiko Juergen Schoenwaelder wrote: > > I think its time to talk about face-to-face meetings. I already > mentioned in a previous email the following events: > > May 24-28, 1999 IM '99 Boston > July 12-16, 1999 45. IETF Oslo > October 11-13, 1999 DSOM '99 Z"urich > November 8-12, 1999 46. IETF Washington > > I got one (!) reply saying that he generally prefers meetings at IETFs > rather than conferences. Given the silence of the other NMRG members, > I propose to > > (a) hold an official NMRG meeting at the IETF in Oslo > > (b) hold an interim NMRG meeting at IM'99 in Boston (since many of > us are going to be at IM'99 anyway) > > I think we should try to get a meeting room in Oslo during the IETF > week - probably on Friday if everything else if filled up. (But we > actually only need a small room - so there is a good chance that > something is available.) We can also try to meet on Sunday before the > IETF week starts - but this needs to be aligned with our travel plans > (so please raise you voice). > > Regarding IM'99, I will arrive in Boston on Saturday 22 and I will > leave on Friday 28. We can either meet on Sunday or on Friday since I > do not plan to attend any of the Friday tutorials. Again, let me know > who will be there so that we can agree where and when to meet. > > 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)