From owner-agentx@dorothy.bmc.com Tue Mar 12 13:06:44 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29531 for ; Tue, 12 Mar 2002 13:06:43 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g2CI9Jt24884; Tue, 12 Mar 2002 12:09:19 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA15952 for agentx-list; Tue, 12 Mar 2002 10:01:07 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA15946 for agentx@dorothy.bmc.com; Tue, 12 Mar 2002 10:01:04 -0800 (PST) Date: Tue, 12 Mar 2002 10:01:04 -0800 (PST) From: Randy Presuhn Message-Id: <200203121801.KAA15946@dorothy.bmc.com> To: agentx@dorothy.bmc.com Subject: RFC 2741 clause 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Content-Transfer-Encoding: 7bit Hi - Dave Perkins' recent query on the SNMPv3 list prompted me to take a look at the AgentX specification's rules for object identifier encoding. Specifically, the ad hoc encoding rules in clause 5.1 of RFC 2741 permit object identifier values that could not be represented in BER. Examples: - a zero-length object identifier; - an object identifier consisting of a single element; - an object identifier in which the first element has a value other than 0, 1, or 2. Three specific sub-cases for each of these come to mind: - notification (snmpTrapOID.0) - varbind values in general - varbind names in general What is a master agent to do if it gets one of these beasts? What is a subagent supposed to do with them? ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-agentx@dorothy.bmc.com Tue Mar 12 17:29:24 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10446 for ; Tue, 12 Mar 2002 17:29:23 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g2CMVvd00511; Tue, 12 Mar 2002 16:31:57 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA17060 for agentx-list; Tue, 12 Mar 2002 14:26:10 -0800 (PST) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA17054; Tue, 12 Mar 2002 14:26:07 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g2CMOGq22582; Tue, 12 Mar 2002 16:24:16 -0600 (CST) Received: from ihemail2.firewall.lucent.com (unknown [192.11.222.163]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 0937020EFFC; Tue, 12 Mar 2002 16:27:36 -0600 (CST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2CMRTp13156; Tue, 12 Mar 2002 17:27:29 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Mar 2002 23:27:28 +0100 Message-ID: From: "Wijnen, Bert (Bert)" To: Randy Presuhn , agentx@dorothy.bmc.com Subject: RE: RFC 2741 clause 5.1 Date: Tue, 12 Mar 2002 23:27:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Inline > -----Original Message----- > From: Randy Presuhn [mailto:rpresuhn@dorothy.bmc.com] > Sent: Tuesday, March 12, 2002 7:01 PM > To: agentx@dorothy.bmc.com > Subject: RFC 2741 clause 5.1 > > > Hi - > > Dave Perkins' recent query on the SNMPv3 list prompted me > to take a look at the AgentX specification's rules for > object identifier encoding. Specifically, the ad hoc > encoding rules in clause 5.1 of RFC 2741 permit object > identifier values that could not be represented in BER. > Examples: > > - a zero-length object identifier; > > - an object identifier consisting of a single element; > > - an object identifier in which the first element has > a value other than 0, 1, or 2. > I think that we mean that they should be valid OIDs, or at least translatable to valid OIDs (for example if we use prefix, then the OID needs to be composed). I do not quickly see where we spell it out though. Maybe when we get our next chance (when/if we adavance to std?) then we should/could add some words to clarify that. > Three specific sub-cases for each of these come to mind: > > - notification (snmpTrapOID.0) > > - varbind values in general > > - varbind names in general > > What is a master agent to do if it gets one of these beasts? > What is a subagent supposed to do with them? > Assuming that we agree that we only want to handle valid OIDs, then I think that step 5 on page 46 migth apply. Bert From owner-agentx@dorothy.bmc.com Tue Mar 12 17:49:05 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10951 for ; Tue, 12 Mar 2002 17:49:04 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g2CMpaE03626; Tue, 12 Mar 2002 16:51:37 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA17278 for agentx-list; Tue, 12 Mar 2002 14:46:21 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA17272 for agentx@dorothy.bmc.com; Tue, 12 Mar 2002 14:46:17 -0800 (PST) Date: Tue, 12 Mar 2002 14:46:17 -0800 (PST) From: Randy Presuhn Message-Id: <200203122246.OAA17272@dorothy.bmc.com> To: agentx@dorothy.bmc.com Subject: RE: RFC 2741 clause 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Content-Transfer-Encoding: 7bit Hi - > Message-ID: > From: "Wijnen, Bert (Bert)" > To: Randy Presuhn , agentx@dorothy.bmc.com > Subject: RE: RFC 2741 clause 5.1 > Date: Tue, 12 Mar 2002 23:27:27 +0100 ... > I think that we mean that they should be valid OIDs, or at least > translatable to valid OIDs (for example if we use prefix, > then the OID needs to be composed). > I do not quickly see where we spell it out though. Indeed, the definition that's currently there defines the n_subid field as having a range of 0 to 128. > Maybe when we get our next chance (when/if we adavance to std?) > then we should/could add some words to clarify that. This seems reasonable to me. ... > Assuming that we agree that we only want to handle valid OIDs, > then I think that step 5 on page 46 migth apply. ... This also seems reasonable to me. Do anyone's test cases currently exercise these syntactic possibilities? ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-agentx@dorothy.bmc.com Tue Mar 12 18:21:30 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11965 for ; Tue, 12 Mar 2002 18:21:29 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g2CNO6I11640; Tue, 12 Mar 2002 17:24:06 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA17651 for agentx-list; Tue, 12 Mar 2002 15:18:52 -0800 (PST) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id PAA17643 for ; Tue, 12 Mar 2002 15:18:47 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g2CNGvK09379 for ; Tue, 12 Mar 2002 17:16:57 -0600 (CST) Received: from mercury.mv.net (unknown [199.125.85.40]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 7302820EF9E for ; Tue, 12 Mar 2002 17:20:17 -0600 (CST) Received: from ieee.org (xbnh-2-28.mv.com [207.22.38.28]) by mercury.mv.net (8.9.3/8.9.3/mem-20020217) with ESMTP id SAA19776 for ; Tue, 12 Mar 2002 18:20:12 -0500 (EST) Message-ID: <3C8E8DCB.227E531F@ieee.org> Date: Tue, 12 Mar 2002 18:22:51 -0500 From: Mark Ellison Organization: Ellison Software Consulting, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: agentx@dorothy.bmc.com Subject: Re: RFC 2741 clause 5.1 References: <200203121801.KAA15946@dorothy.bmc.com> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.mv.net id SAA19776 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id PAA17644 Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Content-Transfer-Encoding: 8bit Hi Randy, This issue reduces to where the OID originates. My comments are inline. Regards, Mark Randy Presuhn wrote: > > Hi - > > Dave Perkins' recent query on the SNMPv3 list prompted me > to take a look at the AgentX specification's rules for > object identifier encoding. Specifically, the ad hoc > encoding rules in clause 5.1 of RFC 2741 permit object > identifier values that could not be represented in BER. > Examples: > > - a zero-length object identifier; From my reading of clause 5.1 this is not possible. I interpret "A null object identifier consists of the 4-byte header with all bytes set to 0" as meaning "0.0" When n_subid=0 and prefix=x, I interpret as "1.3.6.1.x" > > - an object identifier consisting of a single element; > > - an object identifier in which the first element has > a value other than 0, 1, or 2. Could happen under clause 5.1. When presented with this circumstance, EOP clause 7.1.(5) for admin messages provides a means to terminate processing with an error of processingError(268). One could also interpret EOP clause 7.1.(2) as including malformed OIDs, so parseError(266) may also be a remedy for admin messages. I do not see any admin messages where the master originates an OID and transfers to subagent. > > Three specific sub-cases for each of these come to mind: > > - notification (snmpTrapOID.0) > > - varbind values in general > > - varbind names in general > > What is a master agent to do if it gets one of these beasts? > What is a subagent supposed to do with them? Since the master provides the OIDs from the snmp-request to the subagent (EOP 7.2.1.*), it follows that a subagent would not see any malformed OID names or values during its processing (EOP 7.2.2, 7.2.3.*). Should the master receive an agentx response (or agentx-Notify-PDU) with a malformed OID (EOP 7.2.5.*, 7.2.6), the directions are not particularly clear. If the malformed OID is a name, then the object "must be out of view" (my own interpretation). If the malformed OID is a value, then this may not be caught until the SNMP response PDU is being formed. At this time, (RFC 1905 clause 4.2.*) the malformed value would be promoted to a genErr(5) for the error_status of the SNMP response PDU. In a master implemtation that tracks subagent misbehavior, enough promotions to genErr during snmp-response encoding might cause the master to send an agentx-Close-PDU to the offending subagent with a c.reason=reasonOther(1). > > ------------------------------------------------------ > Randy Presuhn BMC Software, Inc. 1-3141 > randy_presuhn@bmc.com 2141 North First Street > Tel: +1 408 546-1006 San José, California 95131 USA > ------------------------------------------------------ > My opinions and BMC's are independent variables. > ------------------------------------------------------ From owner-agentx@dorothy.bmc.com Tue Mar 12 18:42:17 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12364 for ; Tue, 12 Mar 2002 18:42:17 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g2CNiqM15973; Tue, 12 Mar 2002 17:44:52 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA17792 for agentx-list; Tue, 12 Mar 2002 15:39:27 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA17786 for agentx@dorothy.bmc.com; Tue, 12 Mar 2002 15:39:23 -0800 (PST) Date: Tue, 12 Mar 2002 15:39:23 -0800 (PST) From: Randy Presuhn Message-Id: <200203122339.PAA17786@dorothy.bmc.com> To: agentx@dorothy.bmc.com Subject: Re: RFC 2741 clause 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Content-Transfer-Encoding: 8bit Hi - > Message-ID: <3C8E8DCB.227E531F@ieee.org> > Date: Tue, 12 Mar 2002 18:22:51 -0500 > From: Mark Ellison > To: agentx@dorothy.bmc.com > Subject: Re: RFC 2741 clause 5.1 > References: <200203121801.KAA15946@dorothy.bmc.com> > List-Id: IETF Agentx Working Group mailing list ... > > - a zero-length object identifier; > > >From my reading of clause 5.1 this is not possible. > I interpret "A null object identifier consists of the 4-byte header with > all bytes set to 0" as meaning "0.0" The sentence seems backwards. As it is currently worded, it also seems to permit 0.0 to be encoded as 0x020000000000000000000000. ... > > - an object identifier consisting of a single element; > > > > - an object identifier in which the first element has > > a value other than 0, 1, or 2. > > Could happen under clause 5.1. When presented with this circumstance, > EOP clause 7.1.(5) for admin messages provides a means to terminate > processing with an error of processingError(268). > > One could also interpret EOP clause 7.1.(2) as including malformed OIDs, > so parseError(266) may also be a remedy for admin messages. > > I do not see any admin messages where the master originates an OID and > transfers to subagent. > > > > > Three specific sub-cases for each of these come to mind: > > > > - notification (snmpTrapOID.0) > > > > - varbind values in general > > > > - varbind names in general > > > > What is a master agent to do if it gets one of these beasts? > > What is a subagent supposed to do with them? > > Since the master provides the OIDs from the snmp-request to the subagent > (EOP 7.2.1.*), it follows that a subagent would not see any malformed > OID names or values during its processing (EOP 7.2.2, 7.2.3.*). This assumes that master agents are bug-free. > Should the master receive an agentx response (or agentx-Notify-PDU) with > a malformed OID (EOP 7.2.5.*, 7.2.6), the directions are not > particularly clear. > > If the malformed OID is a name, then the object "must be out of view" > (my own interpretation). ... rather than treating it as a parse error, as suggested earlier? If treated as "out of view", the mal-formed thing would have to be sent back by the subagent. I don't like requiring libraries to be able to encode things that are arguably protocol errors. > If the malformed OID is a value, then this may not be caught until the > SNMP response PDU is being formed. At this time, (RFC 1905 clause > 4.2.*) the malformed value would be promoted to a genErr(5) for the > error_status of the SNMP response PDU. In a master implemtation that > tracks subagent misbehavior, enough promotions to genErr during > snmp-response encoding might cause the master to send an > agentx-Close-PDU to the offending subagent with a > c.reason=reasonOther(1). ... For responses to set requests, the "WrongEncoding" error status might be a less catastrophic way to signal these. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-agentx@dorothy.bmc.com Tue Mar 12 19:27:06 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13220 for ; Tue, 12 Mar 2002 19:27:06 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g2D0Te822334; Tue, 12 Mar 2002 18:29:40 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA18312 for agentx-list; Tue, 12 Mar 2002 16:24:18 -0800 (PST) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id QAA18307 for ; Tue, 12 Mar 2002 16:24:13 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g2D0MLT24234 for ; Tue, 12 Mar 2002 18:22:21 -0600 (CST) Received: from mercury.mv.net (unknown [199.125.85.40]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 0FAAD20EF90 for ; Tue, 12 Mar 2002 18:25:41 -0600 (CST) Received: from ieee.org (xbnh-2-31.mv.com [207.22.38.31]) by mercury.mv.net (8.9.3/8.9.3/mem-20020217) with ESMTP id TAA15363 for ; Tue, 12 Mar 2002 19:25:39 -0500 (EST) Message-ID: <3C8E9D22.3A7473DB@ieee.org> Date: Tue, 12 Mar 2002 19:28:18 -0500 From: Mark Ellison Organization: Ellison Software Consulting, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: agentx@dorothy.bmc.com Subject: Re: RFC 2741 clause 5.1 References: <200203122339.PAA17786@dorothy.bmc.com> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.mv.net id TAA15363 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id QAA18308 Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Content-Transfer-Encoding: 8bit Hi Randy, A couple more comments inline. Randy Presuhn wrote: > > Hi - > > > Message-ID: <3C8E8DCB.227E531F@ieee.org> > > Date: Tue, 12 Mar 2002 18:22:51 -0500 > > From: Mark Ellison > > To: agentx@dorothy.bmc.com > > Subject: Re: RFC 2741 clause 5.1 > > References: <200203121801.KAA15946@dorothy.bmc.com> > > List-Id: IETF Agentx Working Group mailing list > ... > > > - a zero-length object identifier; > > > > >From my reading of clause 5.1 this is not possible. > > I interpret "A null object identifier consists of the 4-byte header with > > all bytes set to 0" as meaning "0.0" > > The sentence seems backwards. As it is currently worded, it > also seems to permit 0.0 to be encoded as 0x020000000000000000000000. n_subid=2 with each subid=0 is also a fine way to express "0.0" Both ways are good as far as I'm concerned. > ... > > > - an object identifier consisting of a single element; > > > > > > - an object identifier in which the first element has > > > a value other than 0, 1, or 2. > > > > Could happen under clause 5.1. When presented with this circumstance, > > EOP clause 7.1.(5) for admin messages provides a means to terminate > > processing with an error of processingError(268). > > > > One could also interpret EOP clause 7.1.(2) as including malformed OIDs, > > so parseError(266) may also be a remedy for admin messages. > > > > I do not see any admin messages where the master originates an OID and > > transfers to subagent. > > > > > > > > Three specific sub-cases for each of these come to mind: > > > > > > - notification (snmpTrapOID.0) > > > > > > - varbind values in general > > > > > > - varbind names in general > > > > > > What is a master agent to do if it gets one of these beasts? > > > What is a subagent supposed to do with them? > > > > Since the master provides the OIDs from the snmp-request to the subagent > > (EOP 7.2.1.*), it follows that a subagent would not see any malformed > > OID names or values during its processing (EOP 7.2.2, 7.2.3.*). > > This assumes that master agents are bug-free. Well, the subagent wouldn't see any malformed OID names or values introduced by the AgentX processing within the master. If there is a bug within the master causing such behavior, the fix would be need to occur within the SNMP processing code of the master, and not within the agentx processing code. (Apologies for foisting a misguided assumption when my intention was to reduce and partition the problem :-) > > > Should the master receive an agentx response (or agentx-Notify-PDU) with > > a malformed OID (EOP 7.2.5.*, 7.2.6), the directions are not > > particularly clear. > > > > If the malformed OID is a name, then the object "must be out of view" > > (my own interpretation). > ... > > rather than treating it as a parse error, as suggested earlier? The parse error suggested earlier was for admin messages. The EOP for subagent responses to SNMP protocol messages does not provide explicit text with respect to malformed OIDs. Clause 5.1 allows some degree of freedom for the malformed OID to NOT be a parse error. > If treated as "out of view", the mal-formed thing would have to > be sent back by the subagent. I don't like requiring libraries > to be able to encode things that are arguably protocol errors. I agree. However clause 5.1 does provide some leeway, so could happen. 5.1 allows for OID fragments. > > > If the malformed OID is a value, then this may not be caught until the > > SNMP response PDU is being formed. At this time, (RFC 1905 clause > > 4.2.*) the malformed value would be promoted to a genErr(5) for the > > error_status of the SNMP response PDU. In a master implemtation that > > tracks subagent misbehavior, enough promotions to genErr during > > snmp-response encoding might cause the master to send an > > agentx-Close-PDU to the offending subagent with a > > c.reason=reasonOther(1). > ... > > For responses to set requests, the "WrongEncoding" error > status might be a less catastrophic way to signal these. Assuming that the master is transferring malformed OID names and values (how did these get encoded into the SNMP request in the first place?), then a subagent response with wrongEncodingwrongLength/wrongValue would be a good thing. It would be even better if the master noticed this before propagating and dispatching to the subagent. > > ------------------------------------------------------ > Randy Presuhn BMC Software, Inc. 1-3141 > randy_presuhn@bmc.com 2141 North First Street > Tel: +1 408 546-1006 San José, California 95131 USA > ------------------------------------------------------ > My opinions and BMC's are independent variables. > ------------------------------------------------------ From owner-agentx@dorothy.bmc.com Tue Mar 12 19:38:30 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13487 for ; Tue, 12 Mar 2002 19:38:29 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g2D0f4Y23824; Tue, 12 Mar 2002 18:41:04 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA18369 for agentx-list; Tue, 12 Mar 2002 16:35:34 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA18363 for agentx@dorothy.bmc.com; Tue, 12 Mar 2002 16:35:31 -0800 (PST) Date: Tue, 12 Mar 2002 16:35:31 -0800 (PST) From: Randy Presuhn Message-Id: <200203130035.QAA18363@dorothy.bmc.com> To: agentx@dorothy.bmc.com Subject: Re: RFC 2741 clause 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Content-Transfer-Encoding: 8bit Hi - > Message-ID: <3C8E9D22.3A7473DB@ieee.org> > Date: Tue, 12 Mar 2002 19:28:18 -0500 > From: Mark Ellison > To: agentx@dorothy.bmc.com > Subject: Re: RFC 2741 clause 5.1 > References: <200203122339.PAA17786@dorothy.bmc.com> ... > > For responses to set requests, the "WrongEncoding" error > > status might be a less catastrophic way to signal these. > > Assuming that the master is transferring malformed OID names and values > (how did these get encoded into the SNMP request in the first place?), They couldn't. Either the master agent is getting something ill-formed, is not treating it as a parse error (witness the recent CERT advisory) and is producing a correspondingly bogus agentx encoding; or it is getting something well-formed and has an error in transforming it from BER into the funky agentx encoding. > then a subagent response with wrongEncodingwrongLength/wrongValue would > be a good thing. It would be even better if the master noticed this > before propagating and dispatching to the subagent. ... If all master agents are bug-free, these PDUs won't be perpetrated, except perhaps by Finnish university students. :-) ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-agentx@dorothy.bmc.com Fri Mar 15 13:03:04 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06225 for ; Fri, 15 Mar 2002 13:03:04 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g2FI5HD03238; Fri, 15 Mar 2002 12:05:17 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA13907 for agentx-list; Fri, 15 Mar 2002 09:57:40 -0800 (PST) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA13901; Fri, 15 Mar 2002 09:57:36 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g2FHtiV07380; Fri, 15 Mar 2002 11:55:44 -0600 (CST) Received: from smtprelay9.dc2.adelphia.net (unknown [64.8.50.53]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 9D52520EFAD; Fri, 15 Mar 2002 11:59:05 -0600 (CST) Received: from adelphia.net ([24.49.157.233]) by smtprelay9.dc2.adelphia.net (Netscape Messaging Server 4.15) with ESMTP id GT10MB01.R4Q; Fri, 15 Mar 2002 12:58:59 -0500 Message-ID: <3C9234B8.F25C98DE@adelphia.net> Date: Fri, 15 Mar 2002 12:51:52 -0500 From: Michael Daniele X-Mailer: Mozilla 4.72 [en] (X11; I; OSF1 X5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 To: Randy Presuhn Cc: agentx@dorothy.bmc.com Subject: Re: RFC 2741 clause 5.1 References: <200203121801.KAA15946@dorothy.bmc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Content-Transfer-Encoding: 7bit i think i disagree with the general line of reasoning so far. Randy Presuhn wrote: > Hi - > > Dave Perkins' recent query on the SNMPv3 list prompted me > to take a look at the AgentX specification's rules for > object identifier encoding. Specifically, the ad hoc > encoding rules in clause 5.1 of RFC 2741 permit object > identifier values that could not be represented in BER. > Examples: > > - a zero-length object identifier; > > - an object identifier consisting of a single element; > why, for example, should it be illegal for a subagent to register "1"? > > If all master agents are bug-free, these PDUs won't > be perpetrated, except perhaps by Finnish university > students. :-) > if a master agent is encoding into AgentX an OID that does not have a valid BER representation, then it is going to do so regardless of what AgentX does or doesn't say in its specification. the specification already provides several choices for an AgentX implementation to handle such OIDs. i don't think anything else need be (over) specified. mike From owner-agentx@dorothy.bmc.com Fri Mar 15 13:20:21 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06589 for ; Fri, 15 Mar 2002 13:20:21 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g2FIMtU05981; Fri, 15 Mar 2002 12:22:55 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA14102 for agentx-list; Fri, 15 Mar 2002 10:17:32 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA14096 for agentx@dorothy.bmc.com; Fri, 15 Mar 2002 10:17:29 -0800 (PST) Date: Fri, 15 Mar 2002 10:17:29 -0800 (PST) From: Randy Presuhn Message-Id: <200203151817.KAA14096@dorothy.bmc.com> To: agentx@dorothy.bmc.com Subject: Re: RFC 2741 clause 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Content-Transfer-Encoding: 7bit Hi - > Message-ID: <3C9234B8.F25C98DE@adelphia.net> > Date: Fri, 15 Mar 2002 12:51:52 -0500 > From: Michael Daniele > To: Randy Presuhn > Cc: agentx@dorothy.bmc.com > Subject: Re: RFC 2741 clause 5.1 > References: <200203121801.KAA15946@dorothy.bmc.com> ... > why, for example, should it be illegal for a subagent to register "1"? The AgentX protocol as written appears to allow this. The problem comes when we need to represent the in the AgentX MIB, specifically in the object agentxRegStart, which is defined as a read-only object identifier. If a subagent registers "1", what value should be returned in the response to a get request for this instance of agentxRegStart? > > > > If all master agents are bug-free, these PDUs won't > > be perpetrated, except perhaps by Finnish university > > students. :-) > > > > if a master agent is encoding into AgentX an OID that > does not have a valid BER representation, then it is > going to do so regardless of what AgentX does or doesn't > say in its specification. I think we're in violent agreement on this point. The question is how either entity should respond to these bogus "OIDs". > the specification already provides several choices for an AgentX > implementation to handle such OIDs. I think this is the heart of the problem. Having more than one choice tends to work against interoperability. > i don't think anything else need be (over) specified. ... I don't like overspecification, either, but your example illustrates a case where the protocol lets us do things that the AgentX MIB can't support. I think this is a sub-optimal state of affairs. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-agentx@dorothy.bmc.com Fri Mar 15 14:11:42 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07450 for ; Fri, 15 Mar 2002 14:11:37 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g2FJDjF16100; Fri, 15 Mar 2002 13:13:46 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA14395 for agentx-list; Fri, 15 Mar 2002 11:08:14 -0800 (PST) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA14389; Fri, 15 Mar 2002 11:08:10 -0800 (PST) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g2FJ6IZ28670; Fri, 15 Mar 2002 13:06:18 -0600 (CST) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id CB2261FF015; Fri, 15 Mar 2002 13:09:39 -0600 (CST) Received: from md6370exch001p.wins.lucent.com (h135-114-206-50.lucent.com [135.114.206.50]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2FJ9Nl08865; Fri, 15 Mar 2002 14:09:23 -0500 (EST) Received: by md6370exch001p.nse.lucent.com with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Mar 2002 14:09:23 -0500 Message-ID: From: "Natale, Robert C (Bob)" To: Randy Presuhn , Michael Daniele Cc: agentx@dorothy.bmc.com Subject: RE: RFC 2741 clause 5.1 Date: Fri, 15 Mar 2002 14:09:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Hi folks, > > i don't think anything else need be (over) specified. > ... > > I don't like overspecification, either, but your example > illustrates a case where the protocol lets us do things > that the AgentX MIB can't support. I think this is a > sub-optimal state of affairs. I agree. I think the best way to remove this sub-optimality at this point is to declare an "implementation agreement" that says that white the protocol spec literally allows a single sub- id OID value to be passed in an AgentX PDU it was nor the intent of the WG to allow for representations that break SNMP rules or established SNMP convention in this respect. Hence: a) Sub-agents SHOULD NOT use the single sub-id representation; and b) Master agents MUST NOT use the single sub-id representations; and c) Master agents MUST accept the single sub-id representation from sub-agents but MUST treat it as though it were a minimally sized OID of the form n.m, where n is 0 and m is the single sub-id value passed by the sub-agent. Forgive any gross errors in that suggestion...feel free (anyone, everyone!) to revise it as needed or point out why it must be discarded entirely. Assuming it survives in some recognizable form, we can record it, following WG consensus, in an update to our charter (for posterity's sake) and address it as a clarification change to the specs when they come up for Full standard review down the road. Cordially, BobN From owner-agentx@dorothy.bmc.com Mon Mar 18 01:45:14 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21597 for ; Mon, 18 Mar 2002 01:45:14 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g2I6iWu11789; Mon, 18 Mar 2002 00:44:32 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id VAA05741 for agentx-list; Sun, 17 Mar 2002 21:30:06 -0800 (PST) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id VAA05736 for ; Sun, 17 Mar 2002 21:29:37 -0800 (PST) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g2I5Rgt01541 for ; Sun, 17 Mar 2002 23:27:43 -0600 (CST) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 413201FF053 for ; Sun, 17 Mar 2002 23:31:07 -0600 (CST) Received: from md6370exch001p.wins.lucent.com (h135-114-206-50.lucent.com [135.114.206.50]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2I5UeZ08604 for ; Mon, 18 Mar 2002 00:30:41 -0500 (EST) Received: by md6370exch001p.nse.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Mar 2002 00:30:40 -0500 Message-ID: From: "Natale, Robert C (Bob)" To: Bryan Levin , David Battle Cc: eos@ops.ietf.org, agentx@dorothy.bmc.com Subject: Re: ppt slides for draft-ietf-eos-snmp-bulkdata-01.txt Date: Mon, 18 Mar 2002 00:30:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Hi Bryan and David, I would like to ask you to revise your SNMP Bulk Data Transfer Extensions MIB to include support IETF standard AgentX implementations of it. This would mean adding at least a statement to that effect in Sec. 2.3, "Design Goals" and (most importantly) changing the three scalar objects -- acFileEncoding, acFileCompression, and acXferProtocol -- into table objects in some way. Discussing this latter requirement -- there can be no scalars in a MIB for optimal AgentX implementation -- is complicated at this point by some other possible problems with these object definitions, e.g.: - Should these really be single-valued INTEGERs or bit-masks that represent the range of capabilities in each area offered by the [sub-]agent? The appearance of other objects (xferProtocol, snapshotFileEncoding, and snapshotFileCompression) in several tables suggest the a given [sub-]agent is not limited to just one possibility for acXferProtocol, acFileEncoding, or acFileCompression...? If and when you elect to move those three "ac" objects into tabular form, you can do so by putting them into a table of their own -- perhaps called something like "acProfilesTable" -- indexed via an object called something like "acProfileName" that would be an implementation-specific identifier of snmpAdminString syntax. But I'm just tossing those ideas into the ring...not really trying to micro-design your MIB...the bottom line is that you need to provide a facility for multiple AgentX sub-agents to implement this MIB and you need to move the current scalars into tabular form in some way to do this. I have cc'd the AgentX list on this to invite anyone on that list who is not on the EOS list to engage in this discussion...but perhaps we should keep all follow-up on just the EOS list. Thanks, BobN - - - - - >At 3/17/2002:05:31 PM, snmp@allegronetworks.com wrote: > >can be found on my home server: > > http://www.grateful.net/rfc/bulkdata/ietf-bulk.ppt > >this is what I'm planning to present tomorrow (monday) AM. > >fyi, > >-- >bryan From owner-agentx@dorothy.bmc.com Mon Mar 18 14:54:01 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17613 for ; Mon, 18 Mar 2002 14:54:01 -0500 (EST) From: owner-agentx@dorothy.bmc.com Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g2IJtAo12431; Mon, 18 Mar 2002 13:55:10 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA19092 for agentx-list; Mon, 18 Mar 2002 11:48:29 -0800 (PST) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id FAA17674 for ; Mon, 18 Mar 2002 05:04:44 -0800 (PST) >From: snmp@allegronetworks.com Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g2ID2n125338 for ; Mon, 18 Mar 2002 07:02:49 -0600 (CST) Received: from allegronetworks.com (cottontail.allegronetworks.com [63.115.58.2]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 98E151FF062 for ; Mon, 18 Mar 2002 07:06:14 -0600 (CST) Received: (qmail 10033 invoked by uid 1187); 18 Mar 2002 13:04:51 -0000 Message-ID: <20020318130451.10032.qmail@allegronetworks.com> Subject: Re: ppt slides for draft-ietf-eos-snmp-bulkdata-01.txt To: eos@ops.ietf.org, agentx@dorothy.bmc.com Date: Mon, 18 Mar 2002 05:04:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Content-Transfer-Encoding: 7bit hi bob, thanks for the review comments. >I would like to ask you to revise your SNMP Bulk Data Transfer >Extensions MIB to include support IETF standard AgentX >implementations of it. This would mean adding at least a statement >to that effect in Sec. 2.3, "Design Goals" and (most importantly) >changing the three scalar objects -- acFileEncoding, >acFileCompression, and acXferProtocol -- into table objects in some >way. I didn't consider agent-x and your point is well taken. converting from scalars to tables might be workable. how do you instance the table, though? is there a deterministic mapping of subagents that we can reliably use? >Should these really be single-valued INTEGERs or bit-masks that >represent the range of capabilities in each area offered by the >[sub-]agent? The appearance of other objects (xferProtocol, >snapshotFileEncoding, and snapshotFileCompression) in several tables >suggest the a given [sub-]agent is not limited to just one >possibility for acXferProtocol, acFileEncoding, or >acFileCompression...? that was my error - they were intended to be bitmasks (as a conceptual fix, just OR the enums' together as exponents of 2 until the next mib update; ie, noCompression=1, bzip=2, gzip=4 and then just sum to form the obvious bitmask). cheers, -- bryan From owner-agentx@dorothy.bmc.com Mon Mar 18 21:58:29 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01058 for ; Mon, 18 Mar 2002 21:58:29 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g2J318Y07235; Mon, 18 Mar 2002 21:01:08 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id SAA20795 for agentx-list; Mon, 18 Mar 2002 18:55:33 -0800 (PST) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id SAA20789; Mon, 18 Mar 2002 18:55:27 -0800 (PST) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g2J2rWr20071; Mon, 18 Mar 2002 20:53:32 -0600 (CST) Received: from smtprelay7.dc2.adelphia.net (smtprelay7.dc2.adelphia.net [64.8.50.39]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id BB8AE1FF00E; Mon, 18 Mar 2002 20:56:57 -0600 (CST) Received: from adelphia.net ([24.49.157.233]) by smtprelay7.dc2.adelphia.net (Netscape Messaging Server 4.15 smtprelay7 Dec 7 2001 09:58:59) with ESMTP id GT79IG00.5EC; Mon, 18 Mar 2002 21:56:40 -0500 Message-ID: <3C96A73E.EE8FB950@adelphia.net> Date: Mon, 18 Mar 2002 21:49:34 -0500 From: Michael Daniele X-Mailer: Mozilla 4.72 [en] (X11; I; OSF1 X5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 To: Randy Presuhn Cc: agentx@dorothy.bmc.com Subject: Re: RFC 2741 clause 5.1 References: <200203151817.KAA14096@dorothy.bmc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > Hi - > > > Message-ID: <3C9234B8.F25C98DE@adelphia.net> > > Date: Fri, 15 Mar 2002 12:51:52 -0500 > > From: Michael Daniele > > To: Randy Presuhn > > Cc: agentx@dorothy.bmc.com > > Subject: Re: RFC 2741 clause 5.1 > > References: <200203121801.KAA15946@dorothy.bmc.com> > ... > > why, for example, should it be illegal for a subagent to register "1"? > > The AgentX protocol as written appears to allow this. The > problem comes when we need to represent the in the AgentX MIB, > specifically in the object agentxRegStart, which is defined > as a read-only object identifier. If a subagent registers > "1", what value should be returned in the response to a get > request for this instance of agentxRegStart? that is a good point. i concede :-) mike From owner-agentx@dorothy.bmc.com Mon Mar 18 23:16:25 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03729 for ; Mon, 18 Mar 2002 23:16:25 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g2J4J6L19124; Mon, 18 Mar 2002 22:19:06 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id UAA21008 for agentx-list; Mon, 18 Mar 2002 20:13:35 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id UAA21002; Mon, 18 Mar 2002 20:13:31 -0800 (PST) Date: Mon, 18 Mar 2002 20:13:31 -0800 (PST) From: Randy Presuhn Message-Id: <200203190413.UAA21002@dorothy.bmc.com> To: agentx@dorothy.bmc.com, disman@dorothy.bmc.com Subject: Forged "agentx" postings Cc: bwijnen@lucent.com, randy@psg.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Content-Transfer-Encoding: 7bit Hi - I've just received some "antivirus bounces" that strongly suggest that someone/something is forging posts with a "From" header claiming that they are originating from agentx@dorothy.bmc.com. As far as I can tell, these are NOT being distributed via the working group mailing list, and are probably originating somewhere in Poland. In case someone DOES start trying to use the mailing list to distributed these, I'd like to know in advance whether there would be any objections to configuring the mailing list software used for the DISMAN and AGENTX working groups to block / require list owner approval of any postings containing any of: - MIME multipart/alternative - text/html content-type - attachments ... and similar stuff that's dangerous in the hands of some popular mail readers as commonly configured. This would not affect most legitimate postings at all, but would delay ones that had stuff that the mail filters didn't like. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-agentx@dorothy.bmc.com Mon Mar 18 23:46:18 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04941 for ; Mon, 18 Mar 2002 23:46:18 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g2J4n0f21469; Mon, 18 Mar 2002 22:49:00 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id UAA21266 for agentx-list; Mon, 18 Mar 2002 20:43:43 -0800 (PST) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id UAA21253; Mon, 18 Mar 2002 20:43:34 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g2J4fcY09897; Mon, 18 Mar 2002 22:41:38 -0600 (CST) Received: from hoemail1.firewall.lucent.com (unknown [192.11.226.161]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 9330120EF88; Mon, 18 Mar 2002 22:45:03 -0600 (CST) Received: from md6370exch001p.wins.lucent.com (h135-114-206-50.lucent.com [135.114.206.50]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2J4ivC18752; Mon, 18 Mar 2002 23:44:57 -0500 (EST) Received: by md6370exch001p.nse.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Mar 2002 23:44:56 -0500 Message-ID: From: "Natale, Robert C (Bob)" To: Randy Presuhn , agentx@dorothy.bmc.com, disman@dorothy.bmc.com Cc: "Wijnen, Bert (Bert)" , randy@psg.com Subject: RE: Forged "agentx" postings Date: Mon, 18 Mar 2002 23:44:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Hi Randy, I would encourage you to take any steps you consider appropriate to minimize threats to AgentX list members, including those you outline below. I have noticed a rash of similar bogus postings on other SNMP-related w-mail lists in recent months. These postings most often use a forged From: header that leads one to believe it is coming from a known contributor to the group being targeted. The message structure/content typically makes it obvious upon a quick scan that it is a bogus message with possibly dangerous content. It's truly amazing how much time some people have to waste. Thanks, BobN > -----Original Message----- > From: Randy Presuhn [mailto:rpresuhn@dorothy.bmc.com] > Sent: Monday, March 18, 2002 11:14 PM > To: agentx@dorothy.bmc.com; disman@dorothy.bmc.com > Cc: Wijnen, Bert (Bert); randy@psg.com > Subject: Forged "agentx" postings > > > Hi - > > I've just received some "antivirus bounces" that strongly > suggest that someone/something is forging posts with > a "From" header claiming that they are originating from > agentx@dorothy.bmc.com. As far as I can tell, these > are NOT being distributed via the working group mailing > list, and are probably originating somewhere in Poland. > > In case someone DOES start trying to use the mailing list > to distributed these, I'd like to know in advance whether > there would be any objections to configuring the mailing list > software used for the DISMAN and AGENTX working groups to > block / require list owner approval of any postings containing > any of: > > - MIME multipart/alternative > > - text/html content-type > > - attachments > > ... and similar stuff that's dangerous in the hands of some > popular mail readers as commonly configured. This would > not affect most legitimate postings at all, but would delay > ones that had stuff that the mail filters didn't like. > > ------------------------------------------------------ > Randy Presuhn BMC Software, Inc. 1-3141 > randy_presuhn@bmc.com 2141 North First Street > Tel: +1 408 546-1006 San Jose, California 95131 USA > ------------------------------------------------------ > My opinions and BMC's are independent variables. > ------------------------------------------------------ > From owner-agentx@dorothy.bmc.com Mon Mar 18 23:56:37 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05133 for ; Mon, 18 Mar 2002 23:56:37 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g2J4xJt22215; Mon, 18 Mar 2002 22:59:20 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id UAA21429 for agentx-list; Mon, 18 Mar 2002 20:53:53 -0800 (PST) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id UAA21253; Mon, 18 Mar 2002 20:43:34 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g2J4fcY09897; Mon, 18 Mar 2002 22:41:38 -0600 (CST) Received: from hoemail1.firewall.lucent.com (unknown [192.11.226.161]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 9330120EF88; Mon, 18 Mar 2002 22:45:03 -0600 (CST) Received: from md6370exch001p.wins.lucent.com (h135-114-206-50.lucent.com [135.114.206.50]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2J4ivC18752; Mon, 18 Mar 2002 23:44:57 -0500 (EST) Received: by md6370exch001p.nse.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Mar 2002 23:44:56 -0500 Message-ID: From: "Natale, Robert C (Bob)" To: Randy Presuhn , agentx@dorothy.bmc.com, disman@dorothy.bmc.com Cc: "Wijnen, Bert (Bert)" , randy@psg.com Subject: RE: Forged "agentx" postings Date: Mon, 18 Mar 2002 23:44:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Hi Randy, I would encourage you to take any steps you consider appropriate to minimize threats to AgentX list members, including those you outline below. I have noticed a rash of similar bogus postings on other SNMP-related w-mail lists in recent months. These postings most often use a forged From: header that leads one to believe it is coming from a known contributor to the group being targeted. The message structure/content typically makes it obvious upon a quick scan that it is a bogus message with possibly dangerous content. It's truly amazing how much time some people have to waste. Thanks, BobN > -----Original Message----- > From: Randy Presuhn [mailto:rpresuhn@dorothy.bmc.com] > Sent: Monday, March 18, 2002 11:14 PM > To: agentx@dorothy.bmc.com; disman@dorothy.bmc.com > Cc: Wijnen, Bert (Bert); randy@psg.com > Subject: Forged "agentx" postings > > > Hi - > > I've just received some "antivirus bounces" that strongly > suggest that someone/something is forging posts with > a "From" header claiming that they are originating from > agentx@dorothy.bmc.com. As far as I can tell, these > are NOT being distributed via the working group mailing > list, and are probably originating somewhere in Poland. > > In case someone DOES start trying to use the mailing list > to distributed these, I'd like to know in advance whether > there would be any objections to configuring the mailing list > software used for the DISMAN and AGENTX working groups to > block / require list owner approval of any postings containing > any of: > > - MIME multipart/alternative > > - text/html content-type > > - attachments > > ... and similar stuff that's dangerous in the hands of some > popular mail readers as commonly configured. This would > not affect most legitimate postings at all, but would delay > ones that had stuff that the mail filters didn't like. > > ------------------------------------------------------ > Randy Presuhn BMC Software, Inc. 1-3141 > randy_presuhn@bmc.com 2141 North First Street > Tel: +1 408 546-1006 San Jose, California 95131 USA > ------------------------------------------------------ > My opinions and BMC's are independent variables. > ------------------------------------------------------ > From owner-agentx@dorothy.bmc.com Tue Mar 19 11:01:45 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25231 for ; Tue, 19 Mar 2002 11:01:44 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g2JG3n813447; Tue, 19 Mar 2002 10:03:50 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA04323 for agentx-list; Tue, 19 Mar 2002 07:57:51 -0800 (PST) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA04311; Tue, 19 Mar 2002 07:56:55 -0800 (PST) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g2JFsxg17642; Tue, 19 Mar 2002 09:54:59 -0600 (CST) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id B57C11FF017; Tue, 19 Mar 2002 09:58:24 -0600 (CST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2JFw7L03602; Tue, 19 Mar 2002 10:58:08 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Mar 2002 16:58:06 +0100 Message-ID: From: "Wijnen, Bert (Bert)" To: Randy Presuhn , agentx@dorothy.bmc.com, disman@dorothy.bmc.com Cc: bwijnen@lucent.com, randy@psg.com Subject: RE: Forged "agentx" postings Date: Tue, 19 Mar 2002 15:49:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Sounds good, you have AD support for that Bert > -----Original Message----- > From: Randy Presuhn [mailto:rpresuhn@dorothy.bmc.com] > Sent: Tuesday, March 19, 2002 5:14 AM > To: agentx@dorothy.bmc.com; disman@dorothy.bmc.com > Cc: bwijnen@lucent.com; randy@psg.com > Subject: Forged "agentx" postings > > > Hi - > > I've just received some "antivirus bounces" that strongly > suggest that someone/something is forging posts with > a "From" header claiming that they are originating from > agentx@dorothy.bmc.com. As far as I can tell, these > are NOT being distributed via the working group mailing > list, and are probably originating somewhere in Poland. > > In case someone DOES start trying to use the mailing list > to distributed these, I'd like to know in advance whether > there would be any objections to configuring the mailing list > software used for the DISMAN and AGENTX working groups to > block / require list owner approval of any postings containing > any of: > > - MIME multipart/alternative > > - text/html content-type > > - attachments > > ... and similar stuff that's dangerous in the hands of some > popular mail readers as commonly configured. This would > not affect most legitimate postings at all, but would delay > ones that had stuff that the mail filters didn't like. > > ------------------------------------------------------ > Randy Presuhn BMC Software, Inc. 1-3141 > randy_presuhn@bmc.com 2141 North First Street > Tel: +1 408 546-1006 San Jose, California 95131 USA > ------------------------------------------------------ > My opinions and BMC's are independent variables. > ------------------------------------------------------ >