Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id QAA28094 for nmrg-outgoing; Wed, 31 May 2000 16:02:54 +0200 (MET DST) Received: from wanderer.hardaker.davis.ca.us (IDENT:root@dns2.hardaker.davis.ca.us [168.150.190.2]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id QAA28080; Wed, 31 May 2000 16:02:48 +0200 (MET DST) Received: (from hardaker@localhost) by wanderer.hardaker.davis.ca.us (8.9.3/8.9.3) id HAA01705; Wed, 31 May 2000 07:02:20 -0700 To: lheintz@cisco.com Cc: Juergen Schoenwaelder , snmpv3@lists.tislabs.com, nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] SNMP over TCP transport mapping References: <2413FED0DFE6D111B3F90008C7FA61FB071EC3BF@nl0006exch002u.nl.lucent.com> <3919B235.74F861C4@cisco.com> <200005261549.RAA27766@henkell.ibr.cs.tu-bs.de> <392EB044.BAEFFD93@cisco.com> <200005291001.MAA18937@henkell.ibr.cs.tu-bs.de> <3933F889.2A88B6EE@cisco.com> From: Wes Hardaker X-URL: http://dcas.ucdavis.edu/~hardaker X-Microsoft: Sucks Organization: U.C.Davis, Information Technology - D.C.A.S. 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 Date: 31 May 2000 07:02:18 -0700 In-Reply-To: Lauren Heintz's message of "Tue, 30 May 2000 10:21:13 -0700" Message-ID: Lines: 69 User-Agent: Gnus/5.0805 (Gnus v5.8.5) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO >>>>> On Tue, 30 May 2000 10:21:13 -0700, Lauren Heintz said: Lauren> It just seems counter-intuitive to me to have the server Lauren> (notification generator) initiate connections to clients. >> Who says that the notification originator is the server? Lauren> I'll rephrase: It seems counter-intuitive to me to have the NG Lauren> be the client. Lauren> The direction of data flow is not always the best indicator of Lauren> who the server is; I believe connection mgmt issues more Lauren> properly dictate this. To have the NG be the client entails a Lauren> single client, multiple server paradigm, which seems odd. You're arguments are certainly interesting to consider. However, I too am (still) of the belief that the Notification Generator (NG) is the side that should initiate the connections. However, I do understand your arguments in favor of the reverse. Maybe it would be possible to specify both connection methods in the document, although this seems rather difficult to do as far as connection management goes. Maybe it should be configured at both ends who opens the connection, but then it makes it less "easy-to-use" to the end user that has to walk around to all his boxes and specify who is the client and who is the server. Anyway, consider the following problems with the Notification Responder (NR) opening the TCP connection: 1) It is the responsible for making sure the connection is up and since it is not the one responsible for sending the data, this like a difficult chore. How often should it attempt to make connections to the NG when the last attempt failed or was closed? Certainly when the remote NG comes up and tries to send a linkUp trap it'll be forced to use UDP since the NR couldn't have opened a connection to it yet. 2) The sheer volume of connections required in a large network is huge problem. Consider the (common) case where the number of network boxes is about the size of a class B network and there is one NR configured for most of the network (again, common place setup [though I'd argue that the network administrator has never had problems serious enough that caused his NR to be flooded with requests]). Certainly, I don't want my NR to be attempting connections to all those devices. I'd rather have each device open a connection when they thought they'd need to be sending data that warranted a TCP connection (as opposed to a UDP one). Certainly I don't want the NR opening 255^2 connections that would be required to allow it to accept TCP notifications from each of those possible sources. 3) Many applications are short lived and may wish to send a trap or two while it is up and then shutdown again. Certainly the NR couldn't predict the window when the application might be up and open a connection to it. 4) Multiple applications on the same host might need to send notifications, and hence multiple ports would have to be opened from the NR side. Anyway, due to the above problems I hope you're not suggesting that the NR always be the only one responsible for opening a connection for notifications to be sent through. -- 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 RAA28277 for nmrg-outgoing; Mon, 29 May 2000 17:05:37 +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 RAA28258; Mon, 29 May 2000 17:05:19 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA05395; Mon, 29 May 2000 17:05:08 +0200 Date: Mon, 29 May 2000 17:05:08 +0200 Message-Id: <200005291505.RAA05395@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: dharrington@mediaone.net CC: bwijnen@lucent.com, snmpv3@lists.tislabs.com, nmrg@ibr.cs.tu-bs.de In-reply-to: <39183695.99729C63@mediaone.net> (dharrington@mediaone.net) Subject: Re: [nmrg] SNMP over TCP transport mapping References: <2413FED0DFE6D111B3F90008C7FA61FB071EC3BF@nl0006exch002u.nl.lucent.com> <39183695.99729C63@mediaone.net> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO >>>>> D Harrington writes: D> Comments on SNMP over TCP (draft-irtf-nmrg-snmp-tcp-04.txt) D> 1) footer/header correction - incorrect title fixed D> 2) I am unaccustomed to seeing organization names incorporated into D> the MIB module name and the MODULE-IDENTITY except for private D> MIBs. I am also concerned that having IRTF in the name may cause D> people to consider it purely research and not really usable. Can D> these be made more generic? see previous response D> 3) Section 3 says "applications using SNMP over TCP may choose to D> switch". Would it be more appropriate to say "engines using SNMP D> ..."? fixed D> 4) Section 3 has just a touch of ambiguity between "MUST NOT change D> during a transaction" and "refusing new TCP connections whenever D> necessary". If we dispense with the assumption that a connection is D> opened for a whole transaction, then it is possible that a new D> connection for returning the response for a processed request could D> be refused. Should we add "except during a transaction"? Good point. So far we always assumed that a transaction is carried over a single TCP connection. This needs to be clarified, either by making this assumption explicit or by documenting what happens in this case. D> 5) "requires to transfer" should be "requires the transfer of" fixed D> 6) section 3.3 says "However, SNMP engines MUST NOT discard SNMP D> requests if only the incoming half of the TCP connection is D> closed." It is not obvious to me why this is a MUST NOT. Can you D> add explanatory text that explains the problem with discarding the D> request? see previous response D> 7) "halfs" should be "halves" fixed D> 8) 'noResponse' is not an SNMP error code. Is it defined someplace, D> or is this recommended signal an implementation-dependent action? D> Should there be a recommended SNMP error code for this condition, D> to be returned to the requesting application? or should this just D> be part of the implementation-specific handling of timeouts and D> other connection loss conditions? see previous response D> 9) I have a concern with section 3.4. It is important that D> developers not think that the *contents* of an Inform are D> guaranteed to have been processed when the response is D> received. The receiving engine only acknowledges receipt of the D> inform. I suggest a rewording: D> "There is an important difference between an unconfirmed protocol D> operation sent over a reliable transport and a confirmed protocol D> operation. A reliable transport such as TCP reports that it has D> delivered data to the application process. It does not guarantee D> that D> the data was actually processed in any way by the application D> process." D> "With a confirmed SNMP operation, the receiving SNMP engine D> acknowledges that the data was actually received. Depending on the D> SNMP operation, a confirmation may indicate that further processing D> was done. For example, ..." D> "A reliable transport is thus only a poor approximation for D> confirmed operations. Applications that need confirmation of D> delivery or processing are encouraged to use the confirmed D> operations, such as the InformRequest-PDU, rather than using D> unconfirmed operations, such as traps, over a reliable transport." I have integrated the suggested wordings. D> 10) Is it appropriate to cite URLS in references, given how often D> URLs change in today's world? see previous response D> 11) Should this document use some O&M boilerplate text, such as the D> MIB boilerplate and the security considerations? see previous response Thanks for your comments and the suggested new wordings. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id QAA27659 for nmrg-outgoing; Mon, 29 May 2000 16:53:14 +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 QAA27630; Mon, 29 May 2000 16:53:00 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id QAA04812; Mon, 29 May 2000 16:52:51 +0200 Date: Mon, 29 May 2000 16:52:51 +0200 Message-Id: <200005291452.QAA04812@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: dharrington@mediaone.net CC: bwijnen@lucent.com, snmpv3@lists.tislabs.com, nmrg@ibr.cs.tu-bs.de In-reply-to: <39182895.6DFE0713@mediaone.net> (dharrington@mediaone.net) Subject: Re: [nmrg] SNMP over TCP transport mapping References: <39182895.6DFE0713@mediaone.net> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO >>>>> D Harrington writes: dbh> Comments on TCP over SNMP draft dbh> 1) I think it is atypical to include the name of the authoring dbh> group in the module name, and it will make it difficult to dbh> remember. This also applies to the MODULE-IDENTITY. The prefix allows to move the definitions to the "right" place if they ever go onto the standards track. Of course, if people implement and field the experimental version, then renaming/renumbering will be harder later on. I am open to suggestions - but I guess some folks will scream if the NMRG allocates domains below snmpDomains. Given this, we decided to register everything below the experimental node assigned for the NMRG. Since the IRTF is the hosting organization, we decided to use IRTF-NMRG-SNMP-TM to even prevent name clashes in the IRTF. (Perhaps this is really unlikely and IRTF-SNMP-TM would do the job as well. Opinions welcome.) dbh> 2) I know the issue of IPv6 addresses has been raised numerous dbh> times in the SNMP community. It is my impression that the dbh> community has decided to defer the issue, and supplement existing dbh> definitions in the future by defining addition objects and dbh> textual conventions. On that basis, I consider this IPv4 only dbh> mapping adequate. There will be an ID pretty soon which tries to define generic TCs and domains for transport addresses. I think the SNMPv3 needs to take a close look at it since this ID may pave the way for SNMPv3 over IPv6 transport mappings. dbh> 3) In section 3.3, "halfs" should be "halves" fixed dbh> 4) "However, SNMP engines MUST NOT discard SNMP requests if only dbh> the incoming half of the TCP connection is closed." The text dbh> doesn't explain WHY this rule must be observed, and the reasoning dbh> is not obvious to me. Can this be expanded? See the other postings related to this. It allows some TCP optimization - but it is unclear right now whether the benefits outweight the implementation costs and risks that people do not get it right. dbh> 5) section 3.3 calls for a noResponse error condition. Where is dbh> this error condition defined? Shouldn't the engine also return an dbh> SNMP error code, as enumerated in rfc1905? Which error code would dbh> be appropriate - genErr? or should it be handled by dbh> application-specific timeout handler code? It refers to an application specific timeout handler code. I will try to make that clearer. dbh> 6) section 3.4 says "A confirmed operation indicates that the dbh> data was actually delivered and processed by the receiving dbh> application process." I find this slightly misleading. I dbh> consider it important that developers realize that the receiver dbh> has the option of not processing the *contents* of the Inform. dbh> Could we add ", at least to some degree" to this sentence? The dbh> following examples then illustrate varying degrees. dbh> Alternately, could we reword to "With a reliable transport, the dbh> transport layer reports that the data was delivered to an upper dbh> (application) layer process." "With a confirmed operation, the dbh> application process acknowledges that the data was actually dbh> received." I will try to find better wordings. dbh> 7) Is it appropriate to reference URLs in references? They are not normative and I think they are helpful in an experimental document such as this. dbh> 8) should this have some of the standard boilerplate stuff? the dbh> boilerplate for MIB documents, the security considerations, etc.? dbh> Does it meet all the RFC2223 requirements? I will add the boilerplate and a security section. Thanks for your comments. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id PAA24035 for nmrg-outgoing; Mon, 29 May 2000 15:58:13 +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 PAA24010; Mon, 29 May 2000 15:57:49 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id PAA02311; Mon, 29 May 2000 15:57:40 +0200 Date: Mon, 29 May 2000 15:57:40 +0200 Message-Id: <200005291357.PAA02311@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: fenner@research.att.com CC: snmpv3@lists.tislabs.com, nmrg@ibr.cs.tu-bs.de In-reply-to: <200005270100.SAA19463@windsor.research.att.com> (message from Bill Fenner on Fri, 26 May 2000 18:00:38 -0700) Subject: Re: [nmrg] SNMP over TCP transport mapping References: <200005161902.MAA16360@Dorothy.Bmc.Com> <200005261532.RAA27119@henkell.ibr.cs.tu-bs.de> <200005270100.SAA19463@windsor.research.att.com> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO >>>>> Bill Fenner writes: Bill> Half-closed connections are not necessarily trouble. Consider a Bill> bulk transfer request that can be sent in a single packet Bill> (SYN+data+FIN); the reply can occur on the other half of the TCP Bill> connection while the request side is already closed. Nobody says that half-closed connections are a bad thing. I think the question here is whether optimizations like the one described above make a real difference in operational environments and whether the benefits of allowing them are well balanced with the implementation costs for supporting half-closed connections in all implementations and the risks of potential interoperablity problems if implementors do not get things right. [A good test is probably to challenge the implementations we have today to see whether they handle half-closed connections correctly.] /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id MAA09854 for nmrg-outgoing; Mon, 29 May 2000 12:01:41 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id MAA09833; Mon, 29 May 2000 12:01:15 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id MAA18937; Mon, 29 May 2000 12:01:06 +0200 Date: Mon, 29 May 2000 12:01:06 +0200 Message-Id: <200005291001.MAA18937@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: lheintz@cisco.com CC: snmpv3@lists.tislabs.com, nmrg@ibr.cs.tu-bs.de In-reply-to: <392EB044.BAEFFD93@cisco.com> (message from Lauren Heintz on Fri, 26 May 2000 10:11:32 -0700) Subject: Re: [nmrg] SNMP over TCP transport mapping References: <2413FED0DFE6D111B3F90008C7FA61FB071EC3BF@nl0006exch002u.nl.lucent.com> <3919B235.74F861C4@cisco.com> <200005261549.RAA27766@henkell.ibr.cs.tu-bs.de> <392EB044.BAEFFD93@cisco.com> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO >>>>> Lauren Heintz writes: Lauren> It seems to me that with TCP (and keepalives), a trap receiver Lauren> application can be better designed to *minimize* polling while Lauren> achieving high assurance (maybe even 100% ?) that it knows Lauren> about all outstanding alarm situations at any given moment. Lauren> At this point SNMP trap delivery becomes *just* as reliable Lauren> as, for example, Corba delivery mechanisms. I do not agree with the "nearly or maybe even 100%" statement. If the _sender_ needs to know that his notification reached the receiver(s), then there is no way around an application level acknowledgment. I think IIOP - the protocol behind CORBA - also acknowledges a method invocation unless the method is declared to be oneway. (I guess that CORBA event services are not oneway - but I am not 100% without looking this up.) Lauren> Also, some markets just don't seem willing to accept the Lauren> inform/response model -- I guess believing that TCP mechanisms Lauren> provide for sufficient reliability with lower overhead? If Lauren> true, this doc should indicate that SNMP now meets their Lauren> needs. The SNMP over TCP specification is a technical document and I think it should say what technically is the right answer. For this document, it does not really matter what the market believes. I think the IETF and especially the IRTF makes itself superfluous if they start to document what the market believes rather than the correct technical solutions to a given problem. Lauren> It just seems counter-intuitive to me to have the server Lauren> (notification generator) initiate connections to clients. Who says that the notification originator is the server? Lauren> I'm not suggesting the doc describe an algorithm for managing Lauren> connections, only that because it specifies connections are Lauren> initiated by the server, both server and client Lauren> implementations will suffer, and maybe not be as Lauren> interoperable. Only the notification originator knows when it has to send a notification and to one or multiple notification receivers. So it is the notification originator who can implement reasonable algorithms to keep the amount of resources spend for open connections balanced. It is also the notification originator who has to deal with error situations in case he needs to send a notification but the transport fails. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id RAA04795 for nmrg-outgoing; Fri, 26 May 2000 17:49:12 +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 RAA04778; Fri, 26 May 2000 17:49:06 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA27766; Fri, 26 May 2000 17:49:00 +0200 Date: Fri, 26 May 2000 17:49:00 +0200 Message-Id: <200005261549.RAA27766@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: lheintz@cisco.com CC: snmpv3@lists.tislabs.com, nmrg@ibr.cs.tu-bs.de In-reply-to: <3919B235.74F861C4@cisco.com> (message from Lauren Heintz on Wed, 10 May 2000 12:02:13 -0700) Subject: Re: [nmrg] SNMP over TCP transport mapping References: <2413FED0DFE6D111B3F90008C7FA61FB071EC3BF@nl0006exch002u.nl.lucent.com> <3919B235.74F861C4@cisco.com> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO >>>>> Lauren Heintz writes: Lauren> I have some comments.... Lauren> 3. (1st par) - I've already seen one telecom Element Mgmt Lauren> System opt to use Corba alarm delivery methods instead of Lauren> relying on SNMP UDP traps. I would therefore suggest the Lauren> following rewording of the 1st par to say something like: Lauren> SNMP over TCP is an optional transport Lauren> mapping. Implementors are encouraged to support SNMP over TCP Lauren> whenever possible because this enables applications to make Lauren> more efficient bulk transfers of MIB data [7] and also to Lauren> provide more reliable delivery of alarm messages (i.e traps). No. In fact, the purpose of section 3.4 is actually to explain why TCP does not provide for more reliable delivery of alarm messages. If your management system depends on the delivery of alarm messages, then you need confirmed operations. (Perhaps an indication that the text in section 3.4 is not clear enough...) Lauren> 3.1 - I think it's not clearly stated that two or more Lauren> messages on the same connection MUST not be interleaved Lauren> together. RFC2741, for example, contains the following text: Lauren> The AgentX entity must not "interleave" AgentX PDUs within Lauren> the TCP byte stream. All the bytes of one PDU must be sent Lauren> before any bytes of a different PDU. The receiving entity Lauren> must be prepared for TCP to deliver byte sequences that do not Lauren> coincide with AgentX PDU boundaries. It was so obvious to us that this does not make sense so that nobody cared to write something about it. But such a warning may certainly be helpful for others. Lauren> 3.1 - I gather it's OK for the responding entity to transmit Lauren> responses in an order other than that originally received. Yes. I agree that the text should say that explicitly. Lauren> 3.2 - Since the notification receiver (NR) is to listen for Lauren> connections, does this imply that an SNMP entity that supports Lauren> the target and notification MIBs would implicitly create Lauren> connections to one or more notification receivers at some Lauren> point during MIB configuration, possibly as a side effect to a Lauren> SET request? If so, how and when so? If an NR is taken down Lauren> temporarily but the target/notify MIBs don't change, does the Lauren> NG attempt another connection? Has there been any thought to Lauren> having the notification generator instead do the listening and Lauren> letting the NRs explicitly initiating connections? Seems that Lauren> connection mgmt is easier for NRs, not to mention that the Lauren> number of connections might be more easily minimized in Lauren> environments where such matters are critical. The document does not try to dictate an algorithm for managing connections. I have implemented a strategy which keeps a pool of connections open that are closed if they are inactive or if new connections must be establised. This means that I would not open connections to all potential notification receivers just in case there might be a notification to send. But this is certainly implementation dependent and I can even imagine to have different algorithms in a single package so the user can control which works best in a given environment. Anyway, thanks for your comments. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id RAA04156 for nmrg-outgoing; Fri, 26 May 2000 17:37:43 +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 RAA04151; Fri, 26 May 2000 17:37:39 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA27315; Fri, 26 May 2000 17:37:34 +0200 Date: Fri, 26 May 2000 17:37:34 +0200 Message-Id: <200005261537.RAA27315@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: D.T.Shield@csc.liv.ac.uk CC: snmpv3@lists.tislabs.com, nmrg@ibr.cs.tu-bs.de In-reply-to: <200005101555.QAA19210@daves.staff.csc.liv.ac.uk> (message from Dave Shield on Wed, 10 May 2000 16:55:32 +0100) Subject: Re: [nmrg] SNMP over TCP transport mapping References: <200005101555.QAA19210@daves.staff.csc.liv.ac.uk> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO >>>>> Dave Shield writes: Dave> Section 3.1, paragraph 2 "It is possible to exchange multiple Dave> SNMP request/response pairs over a single connection". Dave> Is this intended to imply a tightly-locked Dave> request/response/request/response alternation, or are Dave> implementors expected to support an asynchronous model Dave> (e.g. request/request/response/request/response/response) ? [I Dave> presume the latter, but it could be read as the former] Your assumption is right. But I agree that we need to be more explicit to avoid mis-understandings. Dave> Is this connection intended to support bidirectional Dave> requests, or will the application opening the connection always Dave> act as the originating engine ? This is particularly relevant Dave> for notification messages, which could travel in either Dave> direction. Kind of unlikely for notification messages. But we should probably say something about it. Dave> Section 3.3, paragraph 2 Dave> The second sentence doesn't really make sense. "The Dave> transport of SNMP messages over UDP requires to transfer large Dave> amounts ...." ^^^^^^^^^^^ Dave> I can understand what it's trying to say, but it's not Dave> particularly clear. I will try to fix up the wordings. Dave> Section 3.3, paragraph 3 Dave> An application needs to support SNMP over UDP as well, so Dave> *will* require the application-level transport management. The Dave> "simpler management application" is unlikely to be realised. Yep. Dave> Section 3.4, paragraph 4 Dave> This refers to "... data passed the transport ...." Dave> Again, it's reasonably clear what this means, but it doesn't Dave> read properly. Will try to fix it in the next revision. Thanks for your comments. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id RAA03986 for nmrg-outgoing; Fri, 26 May 2000 17:32:36 +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 RAA03981; Fri, 26 May 2000 17:32:29 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA27119; Fri, 26 May 2000 17:32:19 +0200 Date: Fri, 26 May 2000 17:32:19 +0200 Message-Id: <200005261532.RAA27119@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: rpresuhn@dorothy.peer.com CC: snmpv3@lists.tislabs.com, nmrg@ibr.cs.tu-bs.de In-reply-to: <200005161902.MAA16360@Dorothy.Bmc.Com> (message from Randy Presuhn on Tue, 16 May 2000 12:02:18 -0700 (PDT)) Subject: Re: [nmrg] SNMP over TCP transport mapping References: <200005161902.MAA16360@Dorothy.Bmc.Com> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO >>>>> Randy Presuhn writes: Randy> This might be a pain to implement consistently across platforms Randy> with different TCP/IP stacks and socket libraries. Wouldn't it Randy> be simpler for applications to just close the socket if either Randy> the incoming or the outgoing half is in trouble? Otherwise, Randy> the half-closed socket would need to be excluded from Randy> poll/select lists input checking (since the descriptor would Randy> always come up ready for read) but be left in the write list Randy> until the application decides to close the socket after writing Randy> the response. This is certainly an option to consider. I agree that not dealing with half closed connections simplifies implementations and is likely to increase interoperability. I will take this back to the NMRG for discussion. Thanks for your comments (and sorry for delayed reaction). /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id NAA11461 for nmrg-outgoing; Fri, 26 May 2000 13:53:01 +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 NAA11427; Fri, 26 May 2000 13:52:39 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id NAA18135; Fri, 26 May 2000 13:52:30 +0200 Date: Fri, 26 May 2000 13:52:30 +0200 Message-Id: <200005261152.NAA18135@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Mike_Ayers@bmc.com CC: kzm@cisco.com, nmrg@ibr.cs.tu-bs.de, snmpv3@lists.tislabs.com In-reply-to: (Mike_Ayers@bmc.com) Subject: Re: [nmrg] SNMP over TCP transport mapping References: Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO >>>>> Ayers, Mike writes: Mike> Equally open to exploitation by barracksroom lawyers, I Mike> suspect. How about: > The SNMP over TCP transport mapping is an optional transport > mapping. SNMP Applications that respond to messages sent via > TCP MUST also respond to messages sent via the UDP transport > mapping as defined in RFC 1906 > and MUST NOT preferentially process messages sent via TCP. [...] Mike> Okay, beat me up now... ;-) I think we can't require that every implementation must _respond_ to messages sent via the UDP transport mapping. We can only require that implementations are in principle able to do so if the user configured it to do so. In other words, we can only require that every conforming implementation _implements_ the UDP transport mapping. I also have serious doubts that we should put out requirements how received messages are handled internally. We have avoided that in the past and I do not see a good reason to do it now. (BTW, there is nothing in RFC 1906 which says similar things for agents that e.g. support SNMP over IPX and SNMP over UDP.) And once again: This SNMP over TCP mapping document is _not_ going on the standards track. So any discussion about compliance is IMHO misplaced (which was one of the main reasons why I rewrote the text Keith proposed - because he argued about compliance). The "since clause" in my proposal had the only purpose to give an explanation for the requirement stated before. Keith and others have problems with this explanation, so I propose to just nuke it. This leads to: > The SNMP over TCP transport mapping is an optional transport > mapping. SNMP protocol engines that implement the SNMP over > TCP transport mapping MUST also implement the SNMP over UDP > transport mapping as defined in RFC 1906 target="refs.RFC1906"/>. I really think this is all we can do. Everything else goes into the old SNMP tradition to not only define the protocol, but also trying to setup rules how people are "permitted" to use the technology. (Don't get me wrong: I am all in favour of recommendations on how to best use a technology. But this clearly belongs into BCP like documents and should not be hard-wired into MUSTs or MUST NOTs in (experimental) protocol specifications.) /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id LAA03139 for nmrg-outgoing; Fri, 26 May 2000 11:07:09 +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 LAA03102; Fri, 26 May 2000 11:06:42 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id LAA10622; Fri, 26 May 2000 11:06:21 +0200 Date: Fri, 26 May 2000 11:06:21 +0200 Message-Id: <200005260906.LAA10622@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: mrozenbl@telcordia.com CC: Mike_Ayers@bmc.com, kzm@cisco.com, nmrg@ibr.cs.tu-bs.de, snmpv3@lists.tislabs.com, rpresuhn@dorothy.peer.com In-reply-to: <852568EA.007FDA90.00@notes950.cc.telcordia.com> (mrozenbl@telcordia.com) Subject: Re: [nmrg] SNMP over TCP transport mapping References: <852568EA.007FDA90.00@notes950.cc.telcordia.com> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO >>>>> Moshe Rozenblit writes: Moshe> I have some concerns about mandating UDP for SNMP. Those Moshe> concerns fall into 3 categories: architecture, security, and Moshe> "Big Brother". [...] I think we are mixing two things up here. I think we need to clearly distinguish between (a) what is required for an SNMP implementation to be conformant and (b) what the operators options are to configure and use conformant SNMP implementations. I agree that every conformant implementation should support SNMP over UDP since this is what guarantees interoperability. This is something the WG should worry about and specify. But the fact that SNMP over UDP is required for implementation conformance does not mean it is "illegal" for an operator to decides to generally disable SNMP over UDP. It is certainly the operators choice and he certainly has to take responsibility what he is doing. The WG should IMHO not try to forbid certain end user configurations. In fact, recommendations about how to configure (or not to configure) systems in certain environments is something that may be best dealt with in a BCP document. Anyway, the whole debate is somewhat moot since SNMP over TCP is going for experimental and talking about compliance in this context is a bit strange. What is far more important are the wordings that end up in the RFC 1906 revision. I personally think the text in RFC 1906 is not as clear as it should be since it talks about "preferred mappings" and "proxy service" and you can very well debate what that means. This perhaps also explains my final comment in my posting yesterday on the rfc1157Domain resolution. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id OAA25338 for nmrg-outgoing; Sat, 20 May 2000 14:28:31 +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 OAA25333; Sat, 20 May 2000 14:28:25 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id OAA19654; Sat, 20 May 2000 14:28:25 +0200 Date: Sat, 20 May 2000 14:28:25 +0200 Message-Id: <200005201228.OAA19654@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: kzm@cisco.com CC: nmrg@ibr.cs.tu-bs.de, snmpv3@lists.tislabs.com In-reply-to: (message from Wes Hardaker on 19 May 2000 16:44:22 -0700) Subject: Re: [nmrg] SNMP over TCP transport mapping References: <200005192046.NAA07189@foxhound.cisco.com> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO Keith> It is non-compliant to this specification to implement and Keith> enable SNMP over TCP without also implementing and concurrently Keith> enabling SNMP over UDP. Wes> I definitely think its well worth saying, regardless. What about the following text: The SNMP over TCP transport mapping is an optional transport mapping. Implementations that implement SNMP over TCP must also implement the SNMP over UDP transport mapping as defined in RFC 1906 since SNMP over UDP provides for the greatest level of interoperability. I think the above text is also pretty clear and it avoids to talk about compliance to an experimental document. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id BAA01875 for nmrg-outgoing; Sat, 20 May 2000 01:44:33 +0200 (MET DST) Received: from wanderer.hardaker.davis.ca.us (IDENT:root@dcas103.ucdavis.edu [169.237.210.103]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id BAA01871 for ; Sat, 20 May 2000 01:44:31 +0200 (MET DST) Received: (from hardaker@localhost) by wanderer.hardaker.davis.ca.us (8.9.3/8.9.3) id QAA06209; Fri, 19 May 2000 16:44:22 -0700 To: Keith McCloghrie Cc: nmrg@ibr.cs.tu-bs.de, snmpv3@lists.tislabs.com Subject: Re: [nmrg] SNMP over TCP transport mapping References: <200005192046.NAA07189@foxhound.cisco.com> From: Wes Hardaker X-URL: http://dcas.ucdavis.edu/~hardaker X-Microsoft: Sucks Organization: U.C.Davis, Information Technology - D.C.A.S. 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 Date: 19 May 2000 16:44:22 -0700 In-Reply-To: Keith McCloghrie's message of "Fri, 19 May 2000 13:46:27 -0700 (PDT)" Message-ID: Lines: 18 User-Agent: Gnus/5.0805 (Gnus v5.8.5) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO >>>>> On Fri, 19 May 2000 13:46:27 -0700 (PDT), Keith McCloghrie said: Keith> It is non-compliant to this specification to implement and enable Keith> SNMP over TCP without also implementing and concurrently enabling Keith> SNMP over UDP. Keith> One can argue that compliance doesn't mean much in an Keith> Experimental RFC, but nevertheless, I suggest that the simplest Keith> and strongest way to say it. I definitely think its well worth saying, regardless. That way if it ever does move towards something stronger than Experimental the note will not be forgotten. -- 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 OAA09496 for nmrg-outgoing; Tue, 16 May 2000 14:55:33 +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 OAA09484; Tue, 16 May 2000 14:55:22 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id OAA12028; Tue, 16 May 2000 14:55:13 +0200 Date: Tue, 16 May 2000 14:55:13 +0200 Message-Id: <200005161255.OAA12028@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: kzm@cisco.com CC: dharrington@mediaone.net, bwijnen@lucent.com, snmpv3@lists.tislabs.com, nmrg@ibr.cs.tu-bs.de In-reply-to: <200005122110.OAA24150@foxhound.cisco.com> (message from Keith McCloghrie on Fri, 12 May 2000 14:10:31 -0700 (PDT)) Subject: Re: [nmrg] SNMP over TCP transport mapping References: <200005122110.OAA24150@foxhound.cisco.com> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO >>>>> Keith McCloghrie writes: Keith> Thus, I suggest the Internet-Draft needs to strength the Keith> following paragraph: Keith> A reliable transport is thus only a poor approximation for Keith> confirmed operations. Applications that need confirmed delivery Keith> of notifications are thus encouraged to use the confirmed Keith> InformRequest-PDU rather than just sending unconfirmed traps Keith> over a reliable transport. Keith> "encouraged to use" here needs to be "can only depend upon" I agree. Keith> No doubt it also needs to provide additional rationale and Keith> "evidence" (such as I present above) in order to overcome the Keith> all too common misunderstanding of what "TCP is reliably" Keith> means. I have added some more text on this issue, although I think that a really detailed explanation probably belongs into a separate document. The misunderstanding of what "TCP is reliable" means is not only present in the SNMP world. Thanks for your comments. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id NAA05285 for nmrg-outgoing; Tue, 16 May 2000 13:39:12 +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 NAA04969; Tue, 16 May 2000 13:32:04 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id NAA08841; Tue, 16 May 2000 13:31:49 +0200 Date: Tue, 16 May 2000 13:31:49 +0200 Message-Id: <200005161131.NAA08841@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: daniele@zk3.dec.com CC: bwijnen@lucent.com, snmpv3@lists.tislabs.com, nmrg@ibr.cs.tu-bs.de In-reply-to: <39181978.5AD3CCD6@zk3.dec.com> (message from Mike Daniele on Tue, 09 May 2000 09:58:16 -0400) Subject: Re: [nmrg] SNMP over TCP transport mapping References: <2413FED0DFE6D111B3F90008C7FA61FB071EC3BF@nl0006exch002u.nl.lucent.com> <39181978.5AD3CCD6@zk3.dec.com> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO >>>>> Mike Daniele writes: Mike> A couple of things in section 3.3 confused me. >> However, SNMP engines MUST NOT discard SNMP requests if only the >> incoming half of the TCP connection is closed. Mike> What is a half of a connection? When one side closes, the Mike> connection is gone. Bill already provided an answer. You can close one half of the bidirectional TCP connection. The purpose of the text is to explain that an engine should continue processing SNMP messages as long as the connection used to send a response is open. I will try to reword this by saying what an engine is required to do (instead of saying what it is not expected to do). Hope this will help to clarify this point. >> A `noResponse' error condition SHOULD be signalled for outstanding >> requests for command generator applications if the TCP connection >> is closed before a response has been received. Mike> Should be signalled by (not for) the command generator Mike> application, right? Yes. Fixed. Thanks for your feedback. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id JAA09511 for nmrg-outgoing; Fri, 12 May 2000 09:25:08 +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 JAA09506; Fri, 12 May 2000 09:25:05 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id JAA02320; Fri, 12 May 2000 09:25:00 +0200 Date: Fri, 12 May 2000 09:25:00 +0200 Message-Id: <200005120725.JAA02320@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: sprenkel@cs.utwente.nl CC: nmrg@ibr.cs.tu-bs.de In-reply-to: <391BB116.78B31223@cs.utwente.nl> (message from Ron Sprenkels on Fri, 12 May 2000 09:21:58 +0200) Subject: Re: [nmrg] Apologies References: <391BB04A.BD9045D6@cs.utwente.nl> <391BB116.78B31223@cs.utwente.nl> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO >>>>> Ron Sprenkels writes: Ron> My apologies for clutering this list with my obvious selection of Ron> the wrong email alias; nmrg is to similar to nm for my email Ron> program :-( Won't happen again I hope. Perhaps you too need some sleep. :-) /js Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id JAA09240 for nmrg-outgoing; Fri, 12 May 2000 09:20:47 +0200 (MET DST) Received: from prodnet.civ.utwente.nl (prodnet.civ.utwente.nl [130.89.1.19]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id JAA09235 for ; Fri, 12 May 2000 09:20:43 +0200 (MET DST) Received: from cs.utwente.nl (ut198100.inbel.utwente.nl [130.89.198.100]) by prodnet.civ.utwente.nl (8.9.3/MQT) with ESMTP id JAA24307; Fri, 12 May 2000 09:20:37 +0200 (METDST) Message-ID: <391BB116.78B31223@cs.utwente.nl> Date: Fri, 12 May 2000 09:21:58 +0200 From: Ron Sprenkels X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Network Management Research Group Subject: [nmrg] Apologies References: <391BB04A.BD9045D6@cs.utwente.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO Hi everybody, My apologies for clutering this list with my obvious selection of the wrong email alias; nmrg is to similar to nm for my email program :-( Won't happen again I hope. 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 JAA08962 for nmrg-outgoing; Fri, 12 May 2000 09:17:22 +0200 (MET DST) Received: from prodnet.civ.utwente.nl (prodnet.civ.utwente.nl [130.89.1.19]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id JAA08957 for ; Fri, 12 May 2000 09:17:20 +0200 (MET DST) Received: from cs.utwente.nl (ut198100.inbel.utwente.nl [130.89.198.100]) by prodnet.civ.utwente.nl (8.9.3/MQT) with ESMTP id JAA23881; Fri, 12 May 2000 09:17:13 +0200 (METDST) Message-ID: <391BB04A.BD9045D6@cs.utwente.nl> Date: Fri, 12 May 2000 09:18:34 +0200 From: Ron Sprenkels X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Network Management Research Group Subject: [nmrg] Coming in later this morning Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO Hi, This morning I'll be at home, to let Joyce catch up on some needed sleep. I'll probably be in around lunch time. If you need me before lunch, feel free to email or call me. 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 VAA01585 for nmrg-outgoing; Thu, 11 May 2000 21:55:38 +0200 (MET DST) Received: from wanderer.hardaker.davis.ca.us (IDENT:root@dcas102.ucdavis.edu [169.237.210.102]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id VAA01581 for ; Thu, 11 May 2000 21:55:36 +0200 (MET DST) Received: (from hardaker@localhost) by wanderer.hardaker.davis.ca.us (8.9.3/8.9.3) id MAA06441; Thu, 11 May 2000 12:55:27 -0700 To: nmrg@ibr.cs.tu-bs.de Subject: [nmrg] ucd-snmp tcp support on a public test agent From: Wes Hardaker X-URL: http://dcas.ucdavis.edu/~hardaker X-Microsoft: Sucks Organization: U.C.Davis, Information Technology - D.C.A.S. 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 Date: 11 May 2000 12:55:27 -0700 Message-ID: Lines: 14 User-Agent: Gnus/5.0805 (Gnus v5.8.5) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO The ucd-snmp demonstration/interoperability agent (see http://ucd-snmp.ucdavis.edu/snmpv3.html) now supports the tcp layer as well. I've actually been meaning to do this for a while, but I only got around to enabling the ability for the agent to open multiple ports yesterday. Anyway, if anyone else is working on TCP support for management apps, you're welcome to use our host as a target for interoperability tests. See the above URL for security names, etc. -- 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 XAA24528 for nmrg-outgoing; Wed, 10 May 2000 23:28:10 +0200 (MET DST) Received: from ihemlsrv.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id XAA24524 for ; Wed, 10 May 2000 23:28:09 +0200 (MET DST) Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id RAA26429 for ; Wed, 10 May 2000 17:28:04 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id RAA26419 for ; Wed, 10 May 2000 17:28:03 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2448.0) id ; Wed, 10 May 2000 23:28:02 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB072F84FF@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: snmpv3@lists.tislabs.com, "Carl W. Kalbfleisch" Cc: Network Management Research Group Subject: RE: [nmrg] SNMP over TCP transport mapping Date: Wed, 10 May 2000 23:25:43 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO There is a widespread mis-understanding of what it means for a document to be Informational, Experimental or Standards track. Many people believe that Experimental means "you're doomed". Not so. Experimental means that we have a specification. We're not sure yet we all agree on all the technicalities and specifications. But we do want people to play and experiment with it, so that we can figure out if the specification makes sense, and is usefull and what needs to be fixed/changed etc. Multiple specs that try to address/solve the same problem (space) may go as experimental so that we can find out by experience as to which protocol/specification makes the most sense to standardize. So certainly, Experimental allows to later move it forward onto the standards track. It is also possible that we find out that it was a bad idea, in which case we probably reclassify it as historic. HHHope this expalins/helps, Bert > ---------- > From: Carl W. Kalbfleisch[SMTP:cwk@verio.net] > Sent: Wednesday, May 10, 2000 10:55 PM > To: Wijnen, Bert (Bert); snmpv3@lists.tislabs.com > Cc: Network Management Research Group > Subject: RE: [nmrg] SNMP over TCP transport mapping > > > Bert, > > What are the implications of publishing as experimental verses standards > track? Could it be moved to standards track later? > > Carl > > > -----Original Message----- > > From: owner-snmpv3@lists.tislabs.com > > [mailto:owner-snmpv3@lists.tislabs.com]On Behalf Of Wijnen, Bert (Bert) > > Sent: Tuesday, May 09, 2000 4:52 AM > > To: snmpv3@lists.tislabs.com > > Cc: Network Management Research Group > > Subject: RE: [nmrg] SNMP over TCP transport mapping > > > > > > I have not (yet) seen any comments on this document. > > So I am starting to assume that the SNMP community at large > > thinks that this is a usefull document and that if we get a > > request to publish it as an Experimental RFC, that I can > > report that the SNMP community seems OK with it. > > If such is the case, then at least a few expressions of > > agreement would be great too. > > > > Thanks, > > Bert > > > > > ---------- > > > From: Juergen Schoenwaelder[SMTP:schoenw@ibr.cs.tu-bs.de] > > > Sent: Monday, May 01, 2000 1:56 PM > > > To: snmpv3@lists.tislabs.com > > > Cc: Network Management Research Group > > > Subject: [nmrg] SNMP over TCP transport mapping > > > > > > > > > The NMRG is ready to submit the SNMP over TCP transport mapping for > > > publication as Experimental RFC. This transport mapping is one of > > > several SNMP extensions to make bulk transfers more efficient. The > > > location of the current ID is: > > > > > > ftp://ietf.org/internet-drafts/draft-irtf-nmrg-snmp-tcp-04.txt > > > > > > The purpose of this message is to make the larger SNMP community aware > > > of this piece of work and to give you a chance to raise any comments > > > before we actually submit the ID to the RFC editor. Please raise any > > > comments before May 12th. > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Technical University Braunschweig > > > Dept. Operating Systems & Computer Networks > > > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, > Germany > > > Fax: +49 531 391 5936 > > > > > > > Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id SAA09485 for nmrg-outgoing; Wed, 10 May 2000 18:59:40 +0200 (MET DST) Received: from wanderer.hardaker.davis.ca.us (IDENT:root@dns2.hardaker.davis.ca.us [168.150.190.2]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id SAA09475 for ; Wed, 10 May 2000 18:59:38 +0200 (MET DST) Received: (from hardaker@localhost) by wanderer.hardaker.davis.ca.us (8.9.3/8.9.3) id JAA01647; Wed, 10 May 2000 09:59:27 -0700 To: Dave Shield Cc: "Wijnen, Bert (Bert)" , snmpv3@lists.tislabs.com, Network Management Research Group Subject: Re: [nmrg] SNMP over TCP transport mapping References: <200005101555.QAA19210@daves.staff.csc.liv.ac.uk> From: Wes Hardaker X-URL: http://dcas.ucdavis.edu/~hardaker X-Microsoft: Sucks Organization: U.C.Davis, Information Technology - D.C.A.S. 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 Date: 10 May 2000 09:59:27 -0700 In-Reply-To: Dave Shield's message of "Wed, 10 May 2000 16:55:32 +0100" Message-ID: Lines: 44 User-Agent: Gnus/5.0805 (Gnus v5.8.5) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO >>>>> On Wed, 10 May 2000 16:55:32 +0100, Dave Shield said: Dave> Section 3.1, paragraph 2 Dave> "It is possible to exchange multiple SNMP request/response pairs Dave> over a single connection". Dave> Is this intended to imply a tightly-locked Dave> request/response/request/response alternation, or are Dave> implementors expected to support an asynchronous model Dave> (e.g. request/request/response/request/response/response) ? [I Dave> presume the latter, but it could be read as the former] Thats certainly a good point, although your assumption that it should be the first is correct. I don't think the document warns about scenarios like: .5requests/1.3requests/response/.2requests/response as well. Dave> Is this connection intended to support bidirectional requests, Dave> or will the application opening the connection always act as the Dave> originating engine ? This is particularly relevant for Dave> notification messages, which could travel in either direction. Well since PDU handling negotiation doesn't exist, then this would rarely be a proper thing to do. Since the notification generator won't know if the other side of the connection is the same process that is supposed to handle traps, it'll most likely need to open a new connection to the (configured) trap handling port. Now, if the incoming request TCP connection originated from the trap handling port then, um, I think it should probably say you still can't use it as its up to the side sending the "request" to initiate the connection. This is somewhat indicated in section 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. Though it doesn't explicitly say you must initiate a new one. Interesting point, though. -- 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 KAA05284 for nmrg-outgoing; Wed, 10 May 2000 10:28:02 +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 KAA05277; Wed, 10 May 2000 10:28:00 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id KAA18052; Wed, 10 May 2000 10:27:57 +0200 Date: Wed, 10 May 2000 10:27:57 +0200 Message-Id: <200005100827.KAA18052@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Network Management Research Group Subject: [nmrg] snmp over tcp discussion Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO Some messages in this thread do not find their way to this list since the sender is not allowed to post here. Since I do not like to manually forward all these messages here, I would like to ask those interested in the whole discussion to subscribe to the snmpv3 mailing list (if not done yet) where you can read all messages. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id WAA20893 for nmrg-outgoing; Tue, 9 May 2000 22:55:14 +0200 (MET DST) Received: from wanderer.hardaker.davis.ca.us (IDENT:root@[169.237.210.75]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id WAA20872 for ; Tue, 9 May 2000 22:54:46 +0200 (MET DST) Received: (from hardaker@localhost) by wanderer.hardaker.davis.ca.us (8.9.3/8.9.3) id NAA14163; Tue, 9 May 2000 13:52:57 -0700 To: Keith McCloghrie Cc: wjhardaker@ucdavis.edu (Wes Hardaker), bwijnen@lucent.com ("Wijnen, Bert (Bert)"), snmpv3@lists.tislabs.com, nmrg@ibr.cs.tu-bs.de (Network Management Research Group) Subject: Re: [nmrg] SNMP over TCP transport mapping References: <200005092016.NAA01246@foxhound.cisco.com> From: Wes Hardaker X-URL: http://dcas.ucdavis.edu/~hardaker X-Microsoft: Sucks Organization: U.C.Davis, Information Technology - D.C.A.S. 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 Date: 09 May 2000 13:52:54 -0700 In-Reply-To: Keith McCloghrie's message of "Tue, 9 May 2000 13:16:19 -0700 (PDT)" Message-ID: Lines: 15 User-Agent: Gnus/5.0805 (Gnus v5.8.5) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO >>>>> On Tue, 9 May 2000 13:16:19 -0700 (PDT), Keith McCloghrie said: Keith> I've seen several examples recently of people wanting to define Keith> MIB objects with a maximum length larger than 256 octets. We Keith> have always advised against this in the past, because of the Keith> need for values to fit within a single SNMP message. FYI, I was referring more to the problem of trying to get large PDUs through that contained a high object count, rather than transmitting objects with a large size... -- 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 TAA09949 for nmrg-outgoing; Tue, 9 May 2000 19:40:33 +0200 (MET DST) Received: from wanderer.hardaker.davis.ca.us (IDENT:root@[169.237.210.75]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id TAA09941 for ; Tue, 9 May 2000 19:40:13 +0200 (MET DST) Received: (from hardaker@localhost) by wanderer.hardaker.davis.ca.us (8.9.3/8.9.3) id KAA08616; Tue, 9 May 2000 10:38:18 -0700 To: "Wijnen, Bert (Bert)" Cc: snmpv3@lists.tislabs.com, Network Management Research Group Subject: Re: [nmrg] SNMP over TCP transport mapping References: <2413FED0DFE6D111B3F90008C7FA61FB071EC3BF@nl0006exch002u.nl.lucent.com> From: Wes Hardaker X-URL: http://dcas.ucdavis.edu/~hardaker X-Microsoft: Sucks Organization: U.C.Davis, Information Technology - D.C.A.S. 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 Date: 09 May 2000 10:38:17 -0700 In-Reply-To: "Wijnen, Bert's message of "Tue, 9 May 2000 11:51:57 +0200" Message-ID: Lines: 22 User-Agent: Gnus/5.0805 (Gnus v5.8.5) XEmacs/21.2 (Shinjuku) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO >>>>> On Tue, 9 May 2000 11:51:57 +0200 , "Wijnen, Bert (Bert)" said: Bert> I have not (yet) seen any comments on this document. So I am Bert> starting to assume that the SNMP community at large thinks that Bert> this is a usefull document and that if we get a request to Bert> publish it as an Experimental RFC, that I can report that the Bert> SNMP community seems OK with it. If such is the case, then at Bert> least a few expressions of agreement would be great too. I've mentioned on the nmrg list (but probably should here) that I'd prefer to see it go forward as something more along the normal standards track rather than the experimental, but either way I agree that it should be published as a formal RFC. The SNMP protocol has been dropped as a possible solution in many other WGs for many reasons, but its lack of TCP support has definitely been one of the more frequently mentioned reasons (usually because of a need for higher packet sizes). -- 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 SAA03940 for nmrg-outgoing; Tue, 9 May 2000 18:04:30 +0200 (MET DST) Received: from chmls05.mediaone.net (ne.mediaone.net [24.128.1.70]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id SAA03936 for ; Tue, 9 May 2000 18:04:28 +0200 (MET DST) Received: from mediaone.net (h00104b8ce2a3.ne.mediaone.net [24.147.177.149]) by chmls05.mediaone.net (8.8.7/8.8.7) with ESMTP id MAA24056; Tue, 9 May 2000 12:04:19 -0400 (EDT) Message-ID: <3918373D.8CAE52EF@mediaone.net> Date: Tue, 09 May 2000 12:05:17 -0400 From: "D. Harrington" X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" , snmpv3@lists.tislabs.com, Network Management Research Group Subject: [nmrg] Re: SNMP/TCP part 4 References: <2413FED0DFE6D111B3F90008C7FA61FB071EC3BF@nl0006exch002u.nl.lucent.com> <39182895.6DFE0713@mediaone.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO Whoops, I thought I'd lost this message before sending, so I wrote a new version and sent it again. They're almost the same. dbh "D. Harrington" wrote: > > Comments on TCP over SNMP draft > > 1) I think it is atypical to include the name of the authoring group in > the module name, and it will make it difficult to remember. This also > applies to the MODULE-IDENTITY. > > 2) I know the issue of IPv6 addresses has been raised numerous times in > the SNMP community. It is my impression that the community has decided > to defer the issue, and supplement existing definitions in the future by > defining addition objects and textual conventions. On that basis, I > consider this IPv4 only mapping adequate. > > 3) In section 3.3, "halfs" should be "halves" > > 4) "However, SNMP engines MUST NOT discard SNMP requests if only the > incoming half of the TCP connection is closed." The text doesn't explain > WHY this rule must be observed, and the reasoning is not obvious to me. > Can this be expanded? > > 5) section 3.3 calls for a noResponse error condition. Where is this > error condition defined? Shouldn't the engine also return an SNMP error > code, as enumerated in rfc1905? Which error code would be appropriate - > genErr? or should it be handled by application-specific timeout handler > code? > > 6) section 3.4 says "A confirmed operation indicates that the data was > actually delivered and processed by the receiving application process." > I find this slightly misleading. I consider it important that developers > realize that the receiver has the option of not processing the > *contents* of the Inform. > > Could we add ", at least to some degree" to this sentence? The following > examples then illustrate varying degrees. > > Alternately, could we reword to > "With a reliable transport, the transport layer reports that the data > was delivered to an upper (application) layer process." > "With a confirmed operation, the application process acknowledges that > the data was actually received." > > 7) Is it appropriate to reference URLs in references? > > 8) should this have some of the standard boilerplate stuff? the > boilerplate for MIB documents, the security considerations, etc.? > Does it meet all the RFC2223 requirements? > > dbh Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id SAA03798 for nmrg-outgoing; Tue, 9 May 2000 18:01:39 +0200 (MET DST) Received: from chmls05.mediaone.net (ne.mediaone.net [24.128.1.70]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id SAA03794 for ; Tue, 9 May 2000 18:01:37 +0200 (MET DST) Received: from mediaone.net (h00104b8ce2a3.ne.mediaone.net [24.147.177.149]) by chmls05.mediaone.net (8.8.7/8.8.7) with ESMTP id MAA23005; Tue, 9 May 2000 12:01:30 -0400 (EDT) Message-ID: <39183695.99729C63@mediaone.net> Date: Tue, 09 May 2000 12:02:29 -0400 From: "D. Harrington" X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: snmpv3@lists.tislabs.com, Network Management Research Group Subject: Re: [nmrg] SNMP over TCP transport mapping References: <2413FED0DFE6D111B3F90008C7FA61FB071EC3BF@nl0006exch002u.nl.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO Comments on SNMP over TCP (draft-irtf-nmrg-snmp-tcp-04.txt) 1) footer/header correction - incorrect title 2) I am unaccustomed to seeing organization names incorporated into the MIB module name and the MODULE-IDENTITY except for private MIBs. I am also concerned that having IRTF in the name may cause people to consider it purely research and not really usable. Can these be made more generic? 3) Section 3 says "applications using SNMP over TCP may choose to switch". Would it be more appropriate to say "engines using SNMP ..."? 4) Section 3 has just a touch of ambiguity between "MUST NOT change during a transaction" and "refusing new TCP connections whenever necessary". If we dispense with the assumption that a connection is opened for a whole transaction, then it is possible that a new connection for returning the response for a processed request could be refused. Should we add "except during a transaction"? 5) "requires to transfer" should be "requires the transfer of" 6) section 3.3 says "However, SNMP engines MUST NOT discard SNMP requests if only the incoming half of the TCP connection is closed." It is not obvious to me why this is a MUST NOT. Can you add explanatory text that explains the problem with discarding the request? 7) "halfs" should be "halves" 8) 'noResponse' is not an SNMP error code. Is it defined someplace, or is this recommended signal an implementation-dependent action? Should there be a recommended SNMP error code for this condition, to be returned to the requesting application? or should this just be part of the implementation-specific handling of timeouts and other connection loss conditions? 9) I have a concern with section 3.4. It is important that developers not think that the *contents* of an Inform are guaranteed to have been processed when the response is received. The receiving engine only acknowledges receipt of the inform. I suggest a rewording: "There is an important difference between an unconfirmed protocol operation sent over a reliable transport and a confirmed protocol operation. A reliable transport such as TCP reports that it has delivered data to the application process. It does not guarantee that the data was actually processed in any way by the application process." "With a confirmed SNMP operation, the receiving SNMP engine acknowledges that the data was actually received. Depending on the SNMP operation, a confirmation may indicate that further processing was done. For example, ..." "A reliable transport is thus only a poor approximation for confirmed operations. Applications that need confirmation of delivery or processing are encouraged to use the confirmed operations, such as the InformRequest-PDU, rather than using unconfirmed operations, such as traps, over a reliable transport." 10) Is it appropriate to cite URLS in references, given how often URLs change in today's world? 11) Should this document use some O&M boilerplate text, such as the MIB boilerplate and the security considerations? Hope this helps, dbh Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id RAA21545 for nmrg-outgoing; Tue, 9 May 2000 17:02:04 +0200 (MET DST) Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.128.1.71]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id RAA21538 for ; Tue, 9 May 2000 17:02:02 +0200 (MET DST) Received: from mediaone.net (h00104b8ce2a3.ne.mediaone.net [24.147.177.149]) by chmls06.mediaone.net (8.8.7/8.8.7) with ESMTP id LAA15259; Tue, 9 May 2000 11:01:46 -0400 (EDT) Message-ID: <39182895.6DFE0713@mediaone.net> Date: Tue, 09 May 2000 11:02:45 -0400 From: "D. Harrington" X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: snmpv3@lists.tislabs.com, Network Management Research Group Subject: Re: [nmrg] SNMP over TCP transport mapping References: <2413FED0DFE6D111B3F90008C7FA61FB071EC3BF@nl0006exch002u.nl.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO Comments on TCP over SNMP draft 1) I think it is atypical to include the name of the authoring group in the module name, and it will make it difficult to remember. This also applies to the MODULE-IDENTITY. 2) I know the issue of IPv6 addresses has been raised numerous times in the SNMP community. It is my impression that the community has decided to defer the issue, and supplement existing definitions in the future by defining addition objects and textual conventions. On that basis, I consider this IPv4 only mapping adequate. 3) In section 3.3, "halfs" should be "halves" 4) "However, SNMP engines MUST NOT discard SNMP requests if only the incoming half of the TCP connection is closed." The text doesn't explain WHY this rule must be observed, and the reasoning is not obvious to me. Can this be expanded? 5) section 3.3 calls for a noResponse error condition. Where is this error condition defined? Shouldn't the engine also return an SNMP error code, as enumerated in rfc1905? Which error code would be appropriate - genErr? or should it be handled by application-specific timeout handler code? 6) section 3.4 says "A confirmed operation indicates that the data was actually delivered and processed by the receiving application process." I find this slightly misleading. I consider it important that developers realize that the receiver has the option of not processing the *contents* of the Inform. Could we add ", at least to some degree" to this sentence? The following examples then illustrate varying degrees. Alternately, could we reword to "With a reliable transport, the transport layer reports that the data was delivered to an upper (application) layer process." "With a confirmed operation, the application process acknowledges that the data was actually received." 7) Is it appropriate to reference URLs in references? 8) should this have some of the standard boilerplate stuff? the boilerplate for MIB documents, the security considerations, etc.? Does it meet all the RFC2223 requirements? dbh Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id PAA16710 for nmrg-outgoing; Tue, 9 May 2000 15:52:43 +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 PAA16697; Tue, 9 May 2000 15:52:29 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id PAA07993; Tue, 9 May 2000 15:52:23 +0200 Date: Tue, 9 May 2000 15:52:23 +0200 Message-Id: <200005091352.PAA07993@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: dharrington@mediaone.net CC: bwijnen@lucent.com, snmpv3@lists.tislabs.com, nmrg@ibr.cs.tu-bs.de In-reply-to: <391813B6.278A632D@mediaone.net> (dharrington@mediaone.net) Subject: Re: [nmrg] SNMP over TCP transport mapping References: <2413FED0DFE6D111B3F90008C7FA61FB071EC3BF@nl0006exch002u.nl.lucent.com> <391813B6.278A632D@mediaone.net> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO >>>>> D Harrington writes: dbh> I'll point out that the footer/header on the document says: [...] dbh> This should probably be fixed before publication. Fixed - and thanks for carefully looking at it. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id PAA15153 for nmrg-outgoing; Tue, 9 May 2000 15:33:06 +0200 (MET DST) Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.128.1.71]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id PAA15149 for ; Tue, 9 May 2000 15:33:02 +0200 (MET DST) Received: from mediaone.net (h00104b8ce2a3.ne.mediaone.net [24.147.177.149]) by chmls06.mediaone.net (8.8.7/8.8.7) with ESMTP id JAA09995; Tue, 9 May 2000 09:32:44 -0400 (EDT) Message-ID: <391813B6.278A632D@mediaone.net> Date: Tue, 09 May 2000 09:33:42 -0400 From: "D. Harrington" X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: snmpv3@lists.tislabs.com, Network Management Research Group Subject: Re: [nmrg] SNMP over TCP transport mapping References: <2413FED0DFE6D111B3F90008C7FA61FB071EC3BF@nl0006exch002u.nl.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO Wel,, I'll point out that the footer/header on the document says: Schoenwaelder Expires October 26, 2000 [Page 1] Internet-Draft TCs for Internet Network Addresses April 2000 This should probably be fixed before publication. This is a very small document. Can we get a few volunteers to sanity check this latest revision before it becomes an Experimental RFC? Thanks, dbh co-chair "Wijnen, Bert (Bert)" wrote: > > I have not (yet) seen any comments on this document. > So I am starting to assume that the SNMP community at large > thinks that this is a usefull document and that if we get a > request to publish it as an Experimental RFC, that I can > report that the SNMP community seems OK with it. > If such is the case, then at least a few expressions of > agreement would be great too. > > Thanks, > Bert > > > ---------- > > From: Juergen Schoenwaelder[SMTP:schoenw@ibr.cs.tu-bs.de] > > Sent: Monday, May 01, 2000 1:56 PM > > To: snmpv3@lists.tislabs.com > > Cc: Network Management Research Group > > Subject: [nmrg] SNMP over TCP transport mapping > > > > > > The NMRG is ready to submit the SNMP over TCP transport mapping for > > publication as Experimental RFC. This transport mapping is one of > > several SNMP extensions to make bulk transfers more efficient. The > > location of the current ID is: > > > > ftp://ietf.org/internet-drafts/draft-irtf-nmrg-snmp-tcp-04.txt > > > > The purpose of this message is to make the larger SNMP community aware > > of this piece of work and to give you a chance to raise any comments > > before we actually submit the ID to the RFC editor. Please raise any > > comments before May 12th. > > > > /js > > > > -- > > Juergen Schoenwaelder Technical University Braunschweig > > Dept. Operating Systems & Computer Networks > > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany > > Fax: +49 531 391 5936 > > > > Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id LAA29782 for nmrg-outgoing; Tue, 9 May 2000 11:52:16 +0200 (MET DST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id LAA29773 for ; Tue, 9 May 2000 11:52:14 +0200 (MET DST) Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id FAA09278 for ; Tue, 9 May 2000 05:52:04 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id FAA09263 for ; Tue, 9 May 2000 05:52:03 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2448.0) id ; Tue, 9 May 2000 11:52:01 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB071EC3BF@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: snmpv3@lists.tislabs.com Cc: Network Management Research Group Subject: RE: [nmrg] SNMP over TCP transport mapping Date: Tue, 9 May 2000 11:51:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO I have not (yet) seen any comments on this document. So I am starting to assume that the SNMP community at large thinks that this is a usefull document and that if we get a request to publish it as an Experimental RFC, that I can report that the SNMP community seems OK with it. If such is the case, then at least a few expressions of agreement would be great too. Thanks, Bert > ---------- > From: Juergen Schoenwaelder[SMTP:schoenw@ibr.cs.tu-bs.de] > Sent: Monday, May 01, 2000 1:56 PM > To: snmpv3@lists.tislabs.com > Cc: Network Management Research Group > Subject: [nmrg] SNMP over TCP transport mapping > > > The NMRG is ready to submit the SNMP over TCP transport mapping for > publication as Experimental RFC. This transport mapping is one of > several SNMP extensions to make bulk transfers more efficient. The > location of the current ID is: > > ftp://ietf.org/internet-drafts/draft-irtf-nmrg-snmp-tcp-04.txt > > The purpose of this message is to make the larger SNMP community aware > of this piece of work and to give you a chance to raise any comments > before we actually submit the ID to the RFC editor. Please raise any > comments before May 12th. > > /js > > -- > Juergen Schoenwaelder Technical University Braunschweig > Dept. Operating Systems & Computer Networks > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany > Fax: +49 531 391 5936 > > Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id NAA07682 for nmrg-outgoing; Mon, 1 May 2000 13:56:49 +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 NAA07662; Mon, 1 May 2000 13:56:41 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id NAA07789; Mon, 1 May 2000 13:56:41 +0200 Date: Mon, 1 May 2000 13:56:41 +0200 Message-Id: <200005011156.NAA07789@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: snmpv3@lists.tislabs.com CC: Network Management Research Group Subject: [nmrg] SNMP over TCP transport mapping Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO The NMRG is ready to submit the SNMP over TCP transport mapping for publication as Experimental RFC. This transport mapping is one of several SNMP extensions to make bulk transfers more efficient. The location of the current ID is: ftp://ietf.org/internet-drafts/draft-irtf-nmrg-snmp-tcp-04.txt The purpose of this message is to make the larger SNMP community aware of this piece of work and to give you a chance to raise any comments before we actually submit the ID to the RFC editor. Please raise any comments before May 12th. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936