Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id LAA18112 for nmrg-outgoing; Fri, 26 Mar 1999 11:09:17 +0100 (MET) Received: from tcomhp20.epfl.ch (tcomhp20.epfl.ch [128.178.151.10]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id LAA18107 for ; Fri, 26 Mar 1999 11:09:15 +0100 (MET) Received: from localhost (tcomhp31.epfl.ch [128.178.151.22]) by tcomhp20.epfl.ch (8.8.8/8.8.8) with ESMTP id LAA18958; Fri, 26 Mar 1999 11:09:15 +0100 (MET) Message-Id: <199903261009.LAA18958@tcomhp20.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 "Thu, 25 Mar 1999 15:03:06 MET." <199903251403.PAA27462@henkell.ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Mar 1999 11:09:14 +0100 Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk On Thu, 25 Mar 1999 15:03:06 +0100, Juergen Schoenwaelder wrote: > > This is an old story. Most RFCs have "Network Working Group" in the > top left corner. You may want to read RFC 2223 section 4 on page 7: I guess I've read too much HTTP material lately :-) > I think we should follow RFC 2223 and keep the tradition alive. Agreed 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 RAA20076 for nmrg-outgoing; Thu, 25 Mar 1999 17:35:56 +0100 (MET) Received: from tecindy.tecsiel.it ([195.103.245.71]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with SMTP id RAA20067; Thu, 25 Mar 1999 17:35:50 +0100 (MET) Received: from tecsiel.it (tecindy.tecsiel.it [193.43.104.23]) by tecindy.tecsiel.it (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA24184; Thu, 25 Mar 1999 17:34:35 +0100 Message-ID: <36FA6599.2A832091@tecsiel.it> Date: Thu, 25 Mar 1999 17:34:33 +0100 From: Luca Deri Reply-To: l.deri@tecsiel.it Organization: Finsiel S.p.A. X-Mailer: Mozilla 4.5 [en] (X11; I; IRIX 6.2 IP22) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Schoenwaelder CC: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] draft-irtf-nmrg-snmp-tcp-00.txt References: <199903231742.SAA08658@henkell.ibr.cs.tu-bs.de> <36F7D6B5.C04DF04E@tecsiel.it> <199903251533.QAA00973@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, > Luca> I would add a sentence saying that manager/agent should try to > Luca> close the connection after a whole PDU has been transmitted > Luca> (i.e. not while a PDU is being sent). > > I have thought quite a while about it. Suppose you are an agent and > you want to send a large response and the TCP connection gets blocked > half way down the road. If you care about your resources, you may want > to close the connection after some time, even though you are in the > middle of a PDU transmission. (BTW, this is what most HTTP servers do > if things don't move forward in a given time window.) The receiver > will recognize that the transmission was aborted and throw away what > he got so far. Right. That's why I've said "..that manager/agent *should* try to..". > 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. IMHO, This sentence is perfect. More comments: [1] >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. The > BER encoded message is then send over a TCP connection. ^^^^^ Fix. [2] Traps In this case the agent (not the manager) has to decide what transport has to be used for sending traps. I would say that a "TCP-enhanced" agent can choose to use TCP depending on the trap size. Nevertheless, if the trapd does not accept TCP connections (i.e. the connection establishment fails) then UDP is used. This allows implementors to maintain a certain degree of backward compatibility. [3] > It might be useful to add more text to this section about when to > choose TCP and when not. Any proposals? UDP MUST be supported whereas TCP is optional (i.e. a) applications may support it b) application that support TCP may decide to switch back to UDP when necessary [see later]). In general originators should be free to use the transport they assume is the best for a certain situation. Nevertheless, TCP costs more than UDP in terms of resource usage. Therefore "TCP-enhanced" applications may choose to switch back (i.e. refuse new TCP connections) to UDP whenever necessary (i.e. too many open connections, resource shortage). Does all this make sense? 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 QAA18257 for nmrg-outgoing; Thu, 25 Mar 1999 16:36:05 +0100 (MET) 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 QAA18217; Thu, 25 Mar 1999 16:34:14 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id QAA00977; Thu, 25 Mar 1999 16:34:14 +0100 Date: Thu, 25 Mar 1999 16:34:14 +0100 Message-Id: <199903251534.QAA00977@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: l.deri@tecsiel.it CC: nmrg@ibr.cs.tu-bs.de In-reply-to: <36F7D6B5.C04DF04E@tecsiel.it> (message from Luca Deri on Tue, 23 Mar 1999 19:00:21 +0100) Subject: Re: [nmrg] draft-irtf-nmrg-snmp-tcp-00.txt References: <199903231742.SAA08658@henkell.ibr.cs.tu-bs.de> <36F7D6B5.C04DF04E@tecsiel.it> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> Luca Deri writes: Luca> [1] >> 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 Luca> I would add a sentence saying that manager/agent should try to Luca> close the connection after a whole PDU has been transmitted Luca> (i.e. not while a PDU is being sent). I have thought quite a while about it. Suppose you are an agent and you want to send a large response and the TCP connection gets blocked half way down the road. If you care about your resources, you may want to close the connection after some time, even though you are in the middle of a PDU transmission. (BTW, this is what most HTTP servers do if things don't move forward in a given time window.) The receiver will recognize that the transmission was aborted and throw away what he got so far. Luca> [2] In addition I would say: - managers can choose the transport Luca> protocol (UDP/TCP) - agents have to reply using the transport Luca> protocol choosed by the manager. I would formulate it a bit different: 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. This also covers informs which may originate from a traditional agent. I have added this text to section 3 now. It might be useful to add more text to this section about when to choose TCP and when not. Any proposals? 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 QAA18224 for nmrg-outgoing; Thu, 25 Mar 1999 16:34:21 +0100 (MET) 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 QAA18198; Thu, 25 Mar 1999 16:33:58 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id QAA00973; Thu, 25 Mar 1999 16:33:58 +0100 Date: Thu, 25 Mar 1999 16:33:58 +0100 Message-Id: <199903251533.QAA00973@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: l.deri@tecsiel.it CC: nmrg@ibr.cs.tu-bs.de In-reply-to: <36F7D6B5.C04DF04E@tecsiel.it> (message from Luca Deri on Tue, 23 Mar 1999 19:00:21 +0100) Subject: Re: [nmrg] draft-irtf-nmrg-snmp-tcp-00.txt References: <199903231742.SAA08658@henkell.ibr.cs.tu-bs.de> <36F7D6B5.C04DF04E@tecsiel.it> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> Luca Deri writes: Luca> [1] >> 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 Luca> I would add a sentence saying that manager/agent should try to Luca> close the connection after a whole PDU has been transmitted Luca> (i.e. not while a PDU is being sent). I have thought quite a while about it. Suppose you are an agent and you want to send a large response and the TCP connection gets blocked half way down the road. If you care about your resources, you may want to close the connection after some time, even though you are in the middle of a PDU transmission. (BTW, this is what most HTTP servers do if things don't move forward in a given time window.) The receiver will recognize that the transmission was aborted and throw away what he got so far. Luca> [2] In addition I would say: - managers can choose the transport Luca> protocol (UDP/TCP) - agents have to reply using the transport Luca> protocol choosed by the manager. I would formulate it a bit different: 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. This also covers informs which may originate from a traditional agent. I have added this text to section 3 now. It might be useful to add more text to this section about when to choose TCP and when not. Any proposals? 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 QAA18206 for nmrg-outgoing; Thu, 25 Mar 1999 16:34:13 +0100 (MET) 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 QAA18201; Thu, 25 Mar 1999 16:34:04 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id QAA00975; Thu, 25 Mar 1999 16:34:04 +0100 Date: Thu, 25 Mar 1999 16:34:04 +0100 Message-Id: <199903251534.QAA00975@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: l.deri@tecsiel.it CC: nmrg@ibr.cs.tu-bs.de In-reply-to: <36F7D6B5.C04DF04E@tecsiel.it> (message from Luca Deri on Tue, 23 Mar 1999 19:00:21 +0100) Subject: Re: [nmrg] draft-irtf-nmrg-snmp-tcp-00.txt References: <199903231742.SAA08658@henkell.ibr.cs.tu-bs.de> <36F7D6B5.C04DF04E@tecsiel.it> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> Luca Deri writes: Luca> [1] >> 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 Luca> I would add a sentence saying that manager/agent should try to Luca> close the connection after a whole PDU has been transmitted Luca> (i.e. not while a PDU is being sent). I have thought quite a while about it. Suppose you are an agent and you want to send a large response and the TCP connection gets blocked half way down the road. If you care about your resources, you may want to close the connection after some time, even though you are in the middle of a PDU transmission. (BTW, this is what most HTTP servers do if things don't move forward in a given time window.) The receiver will recognize that the transmission was aborted and throw away what he got so far. Luca> [2] In addition I would say: - managers can choose the transport Luca> protocol (UDP/TCP) - agents have to reply using the transport Luca> protocol choosed by the manager. I would formulate it a bit different: 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. This also covers informs which may originate from a traditional agent. I have added this text to section 3 now. It might be useful to add more text to this section about when to choose TCP and when not. Any proposals? 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) Date: Thu, 25 Mar 1999 15:03:06 +0100 From: Juergen Schoenwaelder To: martin-flatin@epfl.ch CC: nmrg@ibr.cs.tu-bs.de, martin-flatin@epfl.ch In-reply-to: <199903251347.OAA06033@tcomhp20.epfl.ch> (martin-flatin@epfl.ch) Subject: Re: [nmrg] draft-irtf-nmrg-snmp-tcp-00.txt Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> J P Martin-Flatin writes: >> Network Working Group J> ^^^^^^^^^^^^^^^^^^^^^ Network Management Research Group This is an old story. Most RFCs have "Network Working Group" in the top left corner. You may want to read RFC 2223 section 4 on page 7: : Network Working Group : : The traditional heading for the group that founded the RFC : series. This appears on the first line on the left hand side : of the heading. I think we should follow RFC 2223 and keep the tradition alive. 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) -- !! This message is brought to you via the NMRG mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to . MIME-Version: 1.0 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, 23 Mar 1999 18:42:49 MET." <199903231742.SAA08658@henkell.ibr.cs.tu-bs.de> Date: Thu, 25 Mar 1999 14:47:18 +0100 Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk On Tue, 23 Mar 1999 18:42:49 +0100, Juergen Schoenwaelder wrote: > > 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 ^^^^^^^^^^^^^^^^^^^^^ Network Management Research Group 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/ -- !! This message is brought to you via the NMRG mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to . MIME-Version: 1.0 Date: Tue, 23 Mar 1999 19:00:21 +0100 From: Luca Deri Reply-To: l.deri@tecsiel.it Organization: Finsiel S.p.A. X-Accept-Language: en To: Network Management Research Group Subject: Re: [nmrg] draft-irtf-nmrg-snmp-tcp-00.txt Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Juergen, a few comments: [1] > 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 I would add a sentence saying that manager/agent should try to close the connection after a whole PDU has been transmitted (i.e. not while a PDU is being sent). [2] In addition I would say: - managers can choose the transport protocol (UDP/TCP) - agents have to reply using the transport protocol choosed by the manager. This is because: - if the manager choosed TCP but the reply is very short the agent should reply with UDP because in any case the TCP connection has to be closed -> there's no bandwidth gain is UDP is choosed for the reply - if the manager sends a UDP request that generates a very large reply, the agent is not entitled to choose TCP because otherwise the manager would have to support TCP too but the agent cannot speculate this (i.e. no upward compatibility) 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 -- !! This message is brought to you via the NMRG mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to . Date: Tue, 23 Mar 1999 18:49:08 +0100 From: Juergen Schoenwaelder To: Network Management Research Group Subject: [nmrg] SNMP over TCP Internet Draft Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk I have submitted the SNMP over TCP document as an ID. I fixed a few typos and I turned the definitions into valid SMIv2 (I hope). My idea was to register the definitions in the experimental tree. I asked IANA to reserve a node for the NMRG. However, they need to have an ID first. Thats why the current version uses {experimental xxxx}. Once we get the real assignement from IANA, we can re-submit this ID and use the reserved node for other purposes as well. 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) -- !! This message is brought to you via the NMRG mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to . Date: Tue, 23 Mar 1999 18:42:49 +0100 From: Juergen Schoenwaelder To: internet-drafts@ietf.org CC: Network Management Research Group Subject: [nmrg] draft-irtf-nmrg-snmp-tcp-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 September 1999 23 March 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 January 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 Editor's Address ............................................. 5 6 Full Copyright Statement ..................................... 6 J. Schoenwaelder [Page 2] Internet-Draft SNMP over TCP Transport Mapping January 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. 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. 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 "9903231800Z" 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(xxxx) 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 J. Schoenwaelder [Page 3] Internet-Draft SNMP over TCP Transport Mapping January 1999 SnmpTCPAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d.1d.1d.1d/2d" 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 This is an optional transport mapping. However, implementors are encouraged to support SNMP over TCP whenever possible because this enables applications to use more efficient MIB data transfers. 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. 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. Implementation of larger values is encouraged whenever possible. J. Schoenwaelder [Page 4] Internet-Draft SNMP over TCP Transport Mapping January 1999 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. 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 5. 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 5] Internet-Draft SNMP over TCP Transport Mapping January 1999 6. 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 6] -- !! This message is brought to you via the NMRG mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to . Date: Fri, 19 Mar 1999 18:38:38 +0100 From: Juergen Schoenwaelder To: Subject: [nmrg] some procedural aspects Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Welcome on the NMRG mailing list. Since we are now officially approved as a research group of the Internet Research Task Force (sounds cool), we have to talk about some procedural aspects. 1) mailing list policy I propose to have an open NMRG mailing list policy. This means that the mailing list archive will be publically accessible from the NMRG web page. (I plan to generate a hypermail index so that it is easier to browse the archive using the mouse.) 2) meetings We need to decide where and when we want to have face-to-face meetings. Its usually a good idea to meet at events such as conference, workshops, or IETF meetings in order to reduce travel times and travel costs. Possible events are: 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 think many of us are attending IM '99 in Boston anyway. So I think it is a good place to have our first NMRG face-to-face meeting in Boston. I also think that Oslo is a good place since it is approx. 2 months behind our first meeting and thus a good chance to review how we doing as a group. 3) visibility We need to decide whether we want to announce our existence publically or not. I propose that the NMRG is publically visible. This means that it should be announced in appropriate places, e.g. the editorial of The SimpleTimes. 4) funding One idea behind becoming a research group with a well sounding name is to obtain funds in order to be able to work together. I know that some of us have very limited travel budgets to attend face-to-face meetings. Shall we try to organize some funding as a group or is it up to the individual members to organize fundings for themself? Is there interest (and a volunteer) to organize a proposal for public funding from programs such as TMR of the EU? 5) working documents I expect that this group will produce several working documents. I propose that we use the Internet-Drafts repository for our working documents, at least for technical specifications. This will give us a consistent naming system, it will make our progress visible, and it ensures that specs are accessible from all over the world. (Our NMRG documents will start with draft-irtf-nmrg followed by some document specific name and the usual version number.) I plan to submit the SNMP over TCP spec to the ID repository next week as a first result of the NMRG. There may be other issues we need to talk about. But I think this is enough for now to get things started. (Feel free to bring up any other topics you think are important.) 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) -- !! This message is brought to you via the NMRG mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to . Date: Fri, 19 Mar 1999 09:25:06 +0100 From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de Subject: [nmrg] [brian@hursley.ibm.com: Call for nominations for IRTF Chair] Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Welcome on the NMGR mailing list. I just received the following email from the IAB chair and I am forwarding it here as requested. [This is also a good test to check if this mailing list really works.] Juergen ------- Start of forwarded message ------- Date: Thu, 18 Mar 1999 16:49:27 +0000 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 CC: Harald Tveit Alvestrand , IAB , Rob Austein , Geoff Huston , Ran Atkinson , IESG Subject: Call for nominations for IRTF Chair To: all IRTF members, and other interested parties (Research Group chairs, please forward to your groups). Abel Weinrib has indicated his desire to step down as IRTF and IRSG Chair. It falls to the IAB to appoint his successor, in accordance with RFC 1601 and RFC 2014. The IAB is considering several candidates, but solicits further nominations or self-nominations. These should be addressed IN CONFIDENCE to me, mailto:brian@hursley.ibm.com , by April 15, 1999. (Please don't send your nomination to the cc list of this mail!) I would like to take this opportunity to thank Abel for his efforts over the last several years. Brian Carpenter IAB Chair ------- End of forwarded message ------- -- !! This message is brought to you via the NMRG mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to .