From 2EaP6I6dH@mornin44.net.bmc.com Sun Mar 8 20:21:22 1998 Return-Path: <2EaP6I6dH@mornin44.net.bmc.com> Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id UAA01507 for ; Sun, 8 Mar 1998 20:21:21 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id UAA08352 for ; Sun, 8 Mar 1998 20:20:50 -0600 (CST) From: 2EaP6I6dH@mornin44.net.bmc.com Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma008000; Sun, 8 Mar 98 20:19:26 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id UAA23478 for ; Sun, 8 Mar 1998 20:19:06 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma023321; Sun, 8 Mar 98 20:18:59 -0600 Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id SAA18774 for ; Sun, 8 Mar 1998 18:09:42 -0800 (PST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id UAA06914 for ; Sun, 8 Mar 1998 20:09:41 -0600 (CST) Received: from papayus.topnet.fr(194.51.124.1) by almond.bmc.com via smap (V2.0) id xma006899; Sun, 8 Mar 98 20:09:17 -0600 Received: from A78jNdiXz (unverified [12.70.33.20]) by papayus.topnet.fr (EMWAC SMTPRS 0.83) with SMTP id ; Mon, 09 Mar 1998 00:36:31 +0100 DATE: 08 Mar 98 6:08:23 PM Reply-to: ugothe@power233.com.bmc.com Message-ID: TO: urafriend@3354u.com.bmc.com SUBJECT: How to Improve Your Personal Power HOW ANCIENT TEACHINGS CAN IMPROVE YOUR LIFE TODAY [More information: http://www.popsmart.com] Today everyone is looking for the secrets to health, wealth and happiness. But could the answers to today's questions be contained in the ancient teachings of the Enneagram? Literally translated as "Nine Points," the Enneagram uses a simple yet profound method to help you understand yourself and others better. This knowledge breaks down your previous barriers, leading to greater workplace success and personal fulfillment. The new "Power of 9" program teaches you how to use the teachings of the Enneagram to improve every aspect of your life. Click to http://www.popsmart.com now to find out more. GAIN CRUCIAL KNOWLEDGE FOR SUCCESSFUL PERSONAL AND BUSINESS RELATIONSHIPS Every person's ultimate success is built on the relationships he or she cultivates. For example, would you like to: * Become a better salesperson? * Move up the ladder in your company? * Relate better to your mate? Your children? Parents? Friends? If so, you need to master your relationships, whether with family, Co-workers, or customers. The Power of 9 program helps by giving you a precise understanding of the motivations and desires of others (and yourself as well). When you understand why people act and react in the ways they do, you will master any situation. You'll have the secret to success in everything! To learn more about the Power of Nine program, click to http://www.popsmart.com now. ANSWER THESE QUESTIONS FOR YOURSELF If you understood the motivations and desires of others, could you have more influence on them? If you better understood yourself, would your relationship with your spouse or significant other improve? If you understood what makes others happy or sad, anxious or hopeful, would you have a power that equates to success in everything you do? Yes! The Power of 9 combines the ancient teachings of the Enneagram and solid, up-to-date research in a program that helps you gain unprecedented personal power and happiness. To find out more about the groundbreaking Power of 9 program, click to http://www.popsmart.com now! From iC83Su2V0@msn.com Wed Mar 11 09:26:34 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id JAA00746 for ; Wed, 11 Mar 1998 09:26:33 -0600 (CST) From: iC83Su2V0@msn.com Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id JAA01049 for ; Wed, 11 Mar 1998 09:25:57 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma000577; Wed, 11 Mar 98 09:24:30 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id JAA19833 for ; Wed, 11 Mar 1998 09:24:15 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma019398; Wed, 11 Mar 98 09:23:51 -0600 Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA16023 for ; Wed, 11 Mar 1998 07:13:29 -0800 (PST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id JAA28840 for ; Wed, 11 Mar 1998 09:13:28 -0600 (CST) Received: from unknown(200.247.61.68) by almond.bmc.com via smap (V2.0) id xma028710; Wed, 11 Mar 98 09:13:18 -0600 Received: from H5Eaccqt5 (unverified [166.55.24.213]) by bit.ativanet.com.br (EMWAC SMTPRS 0.83) with SMTP id ; Wed, 11 Mar 1998 13:18:33 -0300 DATE: 11 Mar 98 8:14:42 AM Message-ID: TO: readthis@aol.com SUBJECT: "To the Point" This home based business Works!!!!! 
If you are like me, you are probably needing to earn some extra income. 
I think this will help.

Learn the secret to earning money through the internet.
I am now earning a very healthy income after only 90 days, from the comforts of my home, and you can to.  

* NO MEETINGS TO ATTEND !
* NO SELLING !
* NO PRODUCTS TO STOCK !
* FREE WEB SITE !
* FREE FAX ON DEMAND !
* COMPANY ADVERTISES AND SPONSORS FOR YOU !
* DO NOT HAVE TO DEPEND ON FRIENDS & FAMILY !
* 250,000 CARD DECK MAILINGS MONTHLY !
* 170,000 FULL COLOR BROCHURES SENT !
* PROVEN 1.6 MILLION VISITED WEB PAGE !
* NO HEADACHES, NO HASSLES, NO WORK ! 
 
WHAT THIS PROGRAM IS NOT!

* NOT a chain letter
* NOT a pyramid scheme
* NOT making phone calls
* NOT contacting people
* NOT peddling products
* NOT a scam, con or trick 
 
Please take a minute and E-mail me, with "More Info" in the subject line. I will then send you the link to the Web page that was given to me Free of charge.
My E-mail address is: rohauck@usa.net

Thank You.
Wayne 


For questions regarding this opportunity, please use the contact information in this letter. The return email address does not respond to incoming email. If you are not interested in this offer,  you can be removed from our mailing list by sending an email to remove my email address No subject line or message is necessary, simply send it and your email address  will be automatically removed from our mailing list.
From rpresuhn@dorothy.peer.com Wed Mar 11 11:50:02 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id LAA02694 for ; Wed, 11 Mar 1998 11:50:02 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA11561 for ; Wed, 11 Mar 1998 11:49:24 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma011349; Wed, 11 Mar 98 11:48:26 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA29966 for ; Wed, 11 Mar 1998 11:48:11 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma029654; Wed, 11 Mar 98 11:47:53 -0600 Received: (from rpresuhn@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id JAA17899 for agentx@peer.com; Wed, 11 Mar 1998 09:42:35 -0800 (PST) Date: Wed, 11 Mar 1998 09:42:35 -0800 (PST) From: Randy Presuhn Message-Id: <199803111742.JAA17899@dorothy.peer.com> To: agentx@peer.com Subject: agentx credential delivery Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - There's an interesting issue on the mailing list regarding the implementation of script or expression MIBs as subagents. The problem is that when someone "pushes the button" to run a script or evaluate an expression, it is not sufficient to have validated the access rights of the button-pusher to push the button. (This is handled by access control in the master agent per RFC 2275.) The script or expression evaluation engine needs to dispatch requests on behalf of the button pusher. The information needed to do this is not carried by AgentX SET requests. Background comments from the disman mailing list: >The text that bothered me in is in >the DESCRIPTION of expNameEntry on page 11 where it says: > >| To maintain security of MIB information, when creating a new >| row in this table, the managed system must record the security >| credentials of the requester. >... > >What bothers me is that it records this information as a side effect. >The abstract service interface described in RFC 2271 for delivering the >goods to our command responder application (eventually the instrumentation >of the expression MIB) give us: > >= 4.1.2. Process Incoming Request or Notification PDU >= >= The PDU Dispatcher provides the following primitive to pass an >= incoming SNMP PDU to an application: >= >= processPdu( -- process Request/Notification PDU >= IN messageProcessingModel -- typically, SNMP version >= IN securityModel -- Security Model in use >= IN securityName -- on behalf of this principal >= IN securityLevel -- Level of Security >= IN contextEngineID -- data from/at this SNMP entity >= IN contextName -- data from/in this context >= IN pduVersion -- the version of the PDU >= IN PDU -- SNMP Protocol Data Unit >= IN maxSizeResponseScopedPDU -- maximum size of the Response PDU >= IN stateReference -- reference to state information >= ) -- needed when sending a response > >Unfortunately, RFC 2257 doesn't give us a way to deliver the >securityModel, securityName, and securityLevel information >this application will need as a command generator. Any thoughts on how one might extend AgentX to deliver these three pieces of information? -------------------------- NEW ADDRESS! ------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From bnatale@acecomm.com Wed Mar 11 11:55:45 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id LAA02772 for ; Wed, 11 Mar 1998 11:55:44 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA12888 for ; Wed, 11 Mar 1998 11:55:07 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma012592; Wed, 11 Mar 98 11:53:53 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA05778 for ; Wed, 11 Mar 1998 11:53:35 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma005464; Wed, 11 Mar 98 11:53:22 -0600 Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA18015 for ; Wed, 11 Mar 1998 09:49:16 -0800 (PST) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id LAA00649 for ; Wed, 11 Mar 1998 11:49:11 -0600 (CST) Received: from relay1.smtp.psi.net(38.8.14.2) by cashew.bmc.com via smap (V2.0) id xma000636; Wed, 11 Mar 98 11:49:03 -0600 Received: from nips.acec.com by relay1.smtp.psi.net (8.8.5/SMI-5.4-PSI) id MAA14113; Wed, 11 Mar 1998 12:48:40 -0500 (EST) Received: from bnatale by nips.acec.com (5.65/3.2.083191-ACE*COMM) id AA17627; Wed, 11 Mar 1998 12:49:44 -0500 Message-Id: <3.0.5.32.19980311125213.009495c0@nips.acecomm.com> X-Sender: natale@nips.acecomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 11 Mar 1998 12:52:13 -0500 To: Bob Stewart From: Bob Natale Subject: Re: Security Cc: disman@nexen.com In-Reply-To: <3.0.5.32.19980311113501.0091fdc0@zipper.cisco.com> References: <199803100014.QAA00503@dorothy.peer.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi Bob, >At 11:31 AM 3/11/98 -0500, Bob Stewart wrote: >>Unfortunately, RFC 2257 doesn't give us a way to deliver the >>securityModel, securityName, and securityLevel information >>this application will need as a command generator. > >So you're saying my MIB is a problem because AgentX can't support it? >That sounds like AgentX's problem, not mine. Hmmm...See below. >At 11:35 AM 3/11/98 -0500, Bob Stewart wrote: <...in a slightly different context...> >We can't be expected to design for every weird thing somebody wants >to do for their own twisted reasons. We have to design something >that has a chance of being widely implemented more or less correctly. Must be nice to be able to claim that position for one's own work and yet deny it (above) to others...? In any case, I am confident that AgentX will deal with any new requirements that SNMPv3 presents at the appropriate point in time. This will be done either via some high-level possibly external mechanisms (eg. encrypted sub-agent config files) or via additional AgentX-PDU header fields in a future rev of the protocol. The first kind of approach is how the spec is currently oriented (since the possible specifics of SNMPv3 were unknown at the time); the two kinds of approaches are not necessarily mutually exclusive...it may well be that we'll see an evolutionary process of supporting "secure AgentX sub-agents" and/or that we will see hybrid/mixed configurations existing indefinitely into the future. [I am bcc'ing the AgentX list, just in case there are any AgentXers who aren't on the DISMAN list...if those individuals are interested they should join in the discussion here for now.] Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ---- WinSNMP DLL, SDK, Apps & Agents for Win16/32 & UNIX ---- ------ NetPlus (r) "FCAPS" Telemanagement Applications ------ From wijnen@VNET.IBM.COM Wed Mar 11 13:10:42 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA03783 for ; Wed, 11 Mar 1998 13:10:37 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA00360 for ; Wed, 11 Mar 1998 13:09:46 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma013957; Wed, 11 Mar 98 11:59:12 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA11490 for ; Wed, 11 Mar 1998 11:58:56 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma010788; Wed, 11 Mar 98 11:58:20 -0600 Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA18107; Wed, 11 Mar 1998 09:54:41 -0800 (PST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA12706; Wed, 11 Mar 1998 11:54:38 -0600 (CST) Message-Id: <199803111754.LAA12706@almond.bmc.com> Received: from vnet.ibm.com(204.146.168.194) by almond.bmc.com via smap (V2.0) id xma012468; Wed, 11 Mar 98 11:53:38 -0600 Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R4) with BSMTP id 6781; Wed, 11 Mar 98 12:53:34 EST Date: Wed, 11 Mar 98 18:54:43 CET From: "Bert Wijnen" To: rpresuhn@dorothy.peer.com, agentx@peer.com Subject: agentx credential delivery Ref: Your note of Wed, 11 Mar 1998 09:42:35 -0800 (PST) Subject: Re: agentx credential delivery Mmm... I just posted this to disman... so here it is for the agentX crowd as well. ------------------------- following is a copy ------------------------ Bert Date: Wednesday 11 March 1998, 18:44:53 +0100 (CET) From: Bert Wijnen WIJNEN at UITVM1 To: Bob Stewart bstewart at cisco.com disman at nexen.com Re: Security Ref: Your note of Wed, 11 Mar 1998 11:31:38 -0500 Subject: Security Randy and Bob discuss: > At 04:06 PM 09-03-98 -0800, Randy Presuhn wrote: > >Unfortunately, RFC 2257 doesn't give us a way to deliver the > >securityModel, securityName, and securityLevel information > >this application will need as a command generator. > > So you're saying my MIB is a problem because AgentX can't support it? That > sounds like AgentX's problem, not mine. > Yep it may be an agentX problem. But... let us be fair: - at agentX we decided we want to leave the security issues up to the master agent and we would not want to burden the subagent. - at agentX time (it got published just a month or so ago, but we had it ready in May last year), there was not much certainty about which (if any) security was going to be an SNMP std. - I am personally not in favor of passing security info off to the subagent, certainly not if such is used for further securty handling. However, the securtyModel/Name/Level seem nice definitions that are independent of a specific security mechanism. So passing those along in a future version of agentX would probably be just fine. Certainly if the subagent uses it to pass back to the master-agent security services as input for determining what security needs to be applied to the service being requested by the subagent. Bert From rpresuhn@dorothy.peer.com Wed Mar 11 13:15:45 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA03867 for ; Wed, 11 Mar 1998 13:15:45 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA01633 for ; Wed, 11 Mar 1998 13:15:06 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xmawf0780; Wed, 11 Mar 98 13:13:04 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA20684 for ; Wed, 11 Mar 1998 12:44:23 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma020406; Wed, 11 Mar 98 12:44:05 -0600 Received: (from rpresuhn@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id KAA18482 for agentx@peer.com; Wed, 11 Mar 1998 10:35:00 -0800 (PST) Date: Wed, 11 Mar 1998 10:35:00 -0800 (PST) From: Randy Presuhn Message-Id: <199803111835.KAA18482@dorothy.peer.com> To: agentx@peer.com Subject: Fwd: suggestion for handling security information Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - Dave Perkins requested that I forward this to the distribution list. Enjoy. -------------------------- NEW ADDRESS! ------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- > From dperkins@dsperkins.com Wed Mar 11 10:28:49 PST 1998 > Date: Wed, 11 Mar 98 10:24:56 pst > From: David Perkins > Subject: Re: Security > To: Randy Presuhn > > Randy, > > Im' not on the agentX mailing list, so please act as a "filtering proxy" > for me on this issue. > > In general, most subagents do not need (or want) to see security information > and are "glad" that that their master agent deals with security information. > > However, for those subagents that want to deal with it, then instead of > supplying security information with every call, how about supplying a > new call from a subagent to the master to obtain the security information > for a particular request. It seems that this approach would be backwards > compatible with existing agentX interfaces and also provide security > information when needed. > > Regards, > /dperkins@dsperkins.com, David T. Perkins > Date: 03/11/98, Time: 10:24:56 > > > From daniele@zk3.dec.com Thu Mar 12 09:29:31 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id JAA19933 for ; Thu, 12 Mar 1998 09:29:31 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id JAA27661 for ; Thu, 12 Mar 1998 09:28:51 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma027424; Thu, 12 Mar 98 09:27:47 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id JAA02477 for ; Thu, 12 Mar 1998 09:27:30 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma002062; Thu, 12 Mar 98 09:27:01 -0600 Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA05586; Thu, 12 Mar 1998 07:15:47 -0800 (PST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id JAA25795; Thu, 12 Mar 1998 09:15:46 -0600 (CST) Received: from mail12.digital.com(192.208.46.20) by almond.bmc.com via smap (V2.0) id xma025775; Thu, 12 Mar 98 09:15:28 -0600 Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail12.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id KAA00081; Thu, 12 Mar 1998 10:15:20 -0500 (EST) Received: from bernie.zk3.dec.com by quarry.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA05446; Thu, 12 Mar 1998 10:15:15 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA31739; Thu, 12 Mar 1998 10:12:34 -0500 Message-Id: <9803121512.AA31739@bernie.zk3.dec.com> To: Randy Presuhn Cc: agentx@peer.com Subject: Re: agentx credential delivery In-Reply-To: Your message of "Wed, 11 Mar 98 09:42:35 PST." <199803111742.JAA17899@dorothy.peer.com> Date: Thu, 12 Mar 98 10:12:33 -0500 From: Mike Daniele X-Mts: smtp Hi Randy, I'm confused by this whole thread (in disman). Maybe you can clear it up for me (and maybe for some others) here. (I assume the disman list understands the issues.) >>The text that bothered me in is in >>the DESCRIPTION of expNameEntry on page 11 where it says: >> >>| To maintain security of MIB information, when creating a new >>| row in this table, the managed system must record the security >>| credentials of the requester. >>... >> >>What bothers me is that it records this information as a side effect. This "recording" means within the managed object instrumentation and not within the SNMP security mechanisms themselves, is that correct? If this is correct, is there some reason the MIB can't simply define objects to contain this required information? I'm on the disman list, but haven't been following it much so could be way off base. But this seems like a back-door that violates the SNMP architecture (regardless of AgentX considerations). Thanks, Mike From rpresuhn@dorothy.peer.com Thu Mar 12 11:43:31 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id LAA21323 for ; Thu, 12 Mar 1998 11:43:31 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA07628 for ; Thu, 12 Mar 1998 11:42:51 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma007265; Thu, 12 Mar 98 11:41:21 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA08661 for ; Thu, 12 Mar 1998 11:41:06 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma006847; Thu, 12 Mar 98 11:39:03 -0600 Received: (from rpresuhn@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id JAA06286 for agentx@peer.com; Thu, 12 Mar 1998 09:10:15 -0800 (PST) Date: Thu, 12 Mar 1998 09:10:15 -0800 (PST) From: Randy Presuhn Message-Id: <199803121710.JAA06286@dorothy.peer.com> To: agentx@peer.com Subject: Re: agentx credential delivery Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > To: Randy Presuhn > Cc: agentx@peer.com > Subject: Re: agentx credential delivery > Date: Thu, 12 Mar 98 10:12:33 -0500 > From: Mike Daniele ... > I'm confused by this whole thread (in disman). > > Maybe you can clear it up for me (and maybe for some others) > here. (I assume the disman list understands the issues.) I'll try. > >>The text that bothered me in is in > >>the DESCRIPTION of expNameEntry on page 11 where it says: > >> > >>| To maintain security of MIB information, when creating a new > >>| row in this table, the managed system must record the security > >>| credentials of the requester. > >>... > >> > >>What bothers me is that it records this information as a side effect. > > This "recording" means within the managed object instrumentation > and not within the SNMP security mechanisms themselves, is that correct? Yes. > If this is correct, is there some reason the MIB can't simply > define objects to contain this required information? No. The architecture defined in RFC 2271 supports the flow of this information to a "command responder" via the processPdu abstract service interface described in clause 4.1.2 of RFC 2271. An example of a command responder application would be the master agent side of an AgentX implementation along with its subagents. As a command responder application, it would use the information identifying the originator of the request, security level, and so on as parameters for the access decision function (isAccessAllowed) to decide whether a specific operation should be performed or result returned. So far so good; this fits nicely with the way AgentX works. Where we run into trouble is the requirement to store this information (not directly accessible via management protocol) in a disman expression mib implemented as a subagent. The AgentX protocol does not provide a way to communicate the | IN securityModel -- Security Model in use | IN securityName -- on behalf of this principal | IN securityLevel -- Level of Security parameters to the subagent for storage in conjunction with the MIB objects being created by the SET operation. > I'm on the disman list, but haven't been following it much > so could be way off base. But this seems like a back-door that > violates the SNMP architecture (regardless of AgentX considerations). ... It bothers me too, BUT... The SNMP architecture does not define the agent/subagent abstract service interface. It DOES define the the abstract service interface to a command responder. One way of looking at it is this: processPdu ASI (abstract service interface) | +----------------------+ \ isAccessAllowed | command (Master | \ ASI -------| responder Agent | \ | application part) | \ |......................| architecturally a single . | . command responder, with . subagent . a distributed implementation . protocol . enabled by AgentX protocol. . ASI (NOT defined) . / ........................ / | subagents | / +----------------------+ / The RFC 2271 architecture does not define the internal structure of a (potentially distributed) command responder application, such as a master agent's AgentX support and associated subagents. I believe we were archtecturally correct in AgentX in having the master agent handling the access decision function. The question is whether this additional information (as far as I know, needed only for disman and RMON implementation) should flow in Agentx protocol or should be left outside the scope of AgentX as being one of those "corner cases". I hope this makes the issue (at least as I understand it :-) a bit clearer. -------------------------- NEW ADDRESS! ------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From schoenw@ibr.cs.tu-bs.de Thu Mar 12 13:06:46 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA22258 for ; Thu, 12 Mar 1998 13:06:45 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA13096 for ; Thu, 12 Mar 1998 13:06:05 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma012780; Thu, 12 Mar 98 13:04:48 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA24171 for ; Thu, 12 Mar 1998 13:04:33 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma023572; Thu, 12 Mar 98 13:04:01 -0600 Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA08036; Thu, 12 Mar 1998 10:57:34 -0800 (PST) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id MAA11222; Thu, 12 Mar 1998 12:57:32 -0600 (CST) Received: from ra.ibr.cs.tu-bs.de(134.169.34.12) by cashew.bmc.com via smap (V2.0) id xma011204; Thu, 12 Mar 98 12:57:11 -0600 Received: from henkell.ibr.cs.tu-bs.de (henkell [134.169.34.191]) by ra.ibr.cs.tu-bs.de (8.8.6/8.8.6) with ESMTP id TAA06576; Thu, 12 Mar 1998 19:57:08 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id TAA01629; Thu, 12 Mar 1998 19:57:06 +0100 Date: Thu, 12 Mar 1998 19:57:06 +0100 Message-Id: <199803121857.TAA01629@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: rpresuhn@dorothy.peer.com CC: agentx@peer.com In-reply-to: <199803121710.JAA06286@dorothy.peer.com> (message from Randy Presuhn on Thu, 12 Mar 1998 09:10:15 -0800 (PST)) Subject: Re: agentx credential delivery References: <199803121710.JAA06286@dorothy.peer.com> >>>>> Randy Presuhn writes: Randy> Where we run into trouble is the requirement to store this Randy> information (not directly accessible via management protocol) Randy> in a disman expression mib implemented as a subagent. I do not understand why someone would implement the expression MIB as a subagent. I thought that the expression MIB is bound to "local" MIB variables. At least AgentX does not allow communication between subagents. So all the interesting stuff is not accessible from the expression MIB subagent, at least not without some "backdoors". I think AgentX is fine. We know that AgentX is not designed to handle all possible cases on earth. Juergen -- Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3283) From rpresuhn@dorothy.peer.com Thu Mar 12 13:50:17 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA22813 for ; Thu, 12 Mar 1998 13:50:12 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA17093 for ; Thu, 12 Mar 1998 13:49:32 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma016892; Thu, 12 Mar 98 13:48:51 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA08834 for ; Thu, 12 Mar 1998 13:48:36 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma008373; Thu, 12 Mar 98 13:48:15 -0600 Received: (from rpresuhn@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id LAA09127 for agentx@peer.com; Thu, 12 Mar 1998 11:42:29 -0800 (PST) Date: Thu, 12 Mar 1998 11:42:29 -0800 (PST) From: Randy Presuhn Message-Id: <199803121942.LAA09127@dorothy.peer.com> To: agentx@peer.com Subject: Re: agentx credential delivery Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > Date: Thu, 12 Mar 1998 19:57:06 +0100 > From: Juergen Schoenwaelder > To: rpresuhn@dorothy.peer.com > CC: agentx@peer.com > Subject: Re: agentx credential delivery ... > Randy> Where we run into trouble is the requirement to store this > Randy> information (not directly accessible via management protocol) > Randy> in a disman expression mib implemented as a subagent. > > I do not understand why someone would implement the expression MIB as > a subagent. I thought that the expression MIB is bound to "local" MIB > variables. "Local" MIB variables means that the engineIDs are the same. "Local" doesn't say anything about how the command responder application actually accesses the instrumentation. The expression MIB is a command generator application which happens to be manageable. In a system constructed from subagents, it is still likely that even if the expression mib uses a local mechanism to deliver its requests to the SNMP engine or directly to the command responder, that these requests will then be relayed by the master agent to the relevant subagents using normal subagent protocol mechanisms. (Master agents are at least in some senses components of a command responder application.) > So all the interesting stuff is not accessible from the > expression MIB subagent, at least not without some "backdoors". Consider: | +--------------------------------------------------------+ |(snmp) |(local) | | V +----------------------+ | | +----------------------------+ | disman subagent: | | | +------+ +-------------+ |expression | Command |---+ +->| SNMP | Engine| Master Agent| Agentx /| MIB | generator| |iface | | Interface |--------< +----------------------+ +------+ +-------------+ Protocol\ +----------------------------+ \+-------------------+ | other subagents | +-------------------+ AgentX only describes the subagent/master agent interface. It does not describe the command generator/snmp engine interface. > I think AgentX is fine. We know that AgentX is not designed to handle > all possible cases on earth. I think almost all of us agree on the last point. The question is whether the sort of "ownership" information required at the command responder interface should percolate all the way out to the subagent interface. The disman and rmon mibs suggest that it should, though it DOES bother me. -------------------------- NEW ADDRESS! ------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From daniele@zk3.dec.com Thu Mar 12 14:00:03 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id OAA22951 for ; Thu, 12 Mar 1998 14:00:03 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA18818 for ; Thu, 12 Mar 1998 13:59:24 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma018597; Thu, 12 Mar 98 13:58:24 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA18430 for ; Thu, 12 Mar 1998 13:58:08 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma018130; Thu, 12 Mar 98 13:57:49 -0600 Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA09200; Thu, 12 Mar 1998 11:53:00 -0800 (PST) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id NAA14817; Thu, 12 Mar 1998 13:52:58 -0600 (CST) Received: from mail13.digital.com(192.208.46.30) by cashew.bmc.com via smap (V2.0) id xma014776; Thu, 12 Mar 98 13:52:35 -0600 Received: from flume.zk3.dec.com (flume.zk3.dec.com [16.140.112.3]) by mail13.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id OAA24974; Thu, 12 Mar 1998 14:52:28 -0500 (EST) Received: from bernie.zk3.dec.com by flume.zk3.dec.com (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA15467; Thu, 12 Mar 1998 14:52:27 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA31990; Thu, 12 Mar 1998 14:49:45 -0500 Message-Id: <9803121949.AA31990@bernie.zk3.dec.com> To: Randy Presuhn Cc: agentx@peer.com Subject: Re: agentx credential delivery In-Reply-To: Your message of "Thu, 12 Mar 98 09:10:15 PST." <199803121710.JAA06286@dorothy.peer.com> Date: Thu, 12 Mar 98 14:49:45 -0500 From: Mike Daniele X-Mts: smtp Randy, >> If this is correct, is there some reason the MIB can't simply >> define objects to contain this required information? >No. The architecture defined in RFC 2271 supports the flow of this >information to a "command responder" via the processPdu abstract service >interface described in clause 4.1.2 of RFC 2271. What I was asking is, why can't the manager application pass whatever is needed to perform a request, within the variable bindings in the request? >Where we run into trouble is the requirement to store this information >(not directly accessible via management protocol) in a disman expression >mib... Why isn't it accessible via management protocol? >It bothers me too, BUT... >The SNMP architecture does not define the agent/subagent abstract >service interface. It DOES define the the abstract service >interface to a command responder. One way of looking at it is this: Unrelated to AgentX (but I'll discuss it here anyway :-), I think this is oversimplifying. >= processPdu( -- process Request/Notification PDU >= IN messageProcessingModel -- typically, SNMP version >= IN securityModel -- Security Model in use >= IN securityName -- on behalf of this principal >= IN securityLevel -- Level of Security >= IN contextEngineID -- data from/at this SNMP entity >= IN contextName -- data from/in this context >= IN pduVersion -- the version of the PDU >= IN PDU -- SNMP Protocol Data Unit >= IN maxSizeResponseScopedPDU -- maximum size of the Response PDU >= IN stateReference -- reference to state information > Note that the PDU is separate from the security information. RFC 2273 says (under Command Responder Applications): (5) The management operation represented by the SNMPv2 operation type is performed with respect to the relevant MIB view within the context named by the contextName, according to the procedures set forth in [RFC1905]. The relevant MIB view is determined by the securityLevel, securityModel, contextName, securityName, and SNMPv2 operation type. To determine whether a particular object instance is within the relevant MIB view, the following abstract service interface is called: statusInformation = -- success or errorIndication isAccessAllowed( IN securityModel -- Security Model in use IN securityName -- principal who wants to access IN securityLevel -- Level of Security IN viewType -- read, write, or notify view IN contextName -- context containing variableName IN variableName -- OID for the managed object ) Although not specifically stated, it seems obvious that the security information is here solely for determining if the variableName is within view. RFC 1905 defines variable binding validation, and creation/value assignment, only in terms of what is passed in the PDU. So I think an argument could be made that it (disman) violates the SNMP architecture (as a whole, not just RFC 2271). Whether it does or not, it certainly seems to violate any sense of propriety :-) Modular design, layering, that kind of thing. As to AgentX: >>Unfortunately, RFC 2257 doesn't give us a way to deliver the >>securityModel, securityName, and securityLevel information >>this application will need as a command generator. >Any thoughts on how one might extend AgentX to deliver these three >pieces of information? If it's delivered at all, it would invalidate section 9 item 2 of RFC 2257, wouldn't it? Mike From wijnen@vnet.IBM.COM Thu Mar 12 14:20:58 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id OAA23217 for ; Thu, 12 Mar 1998 14:20:58 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA21075 for ; Thu, 12 Mar 1998 14:20:20 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma020721; Thu, 12 Mar 98 14:19:07 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA09672 for ; Thu, 12 Mar 1998 14:18:52 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma009237; Thu, 12 Mar 98 14:18:32 -0600 Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA09502; Thu, 12 Mar 1998 12:13:29 -0800 (PST) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id OAA16034; Thu, 12 Mar 1998 14:13:27 -0600 (CST) Message-Id: <199803122013.OAA16034@cashew.bmc.com> Received: from vnet.ibm.com(204.146.168.194) by cashew.bmc.com via smap (V2.0) id xma016004; Thu, 12 Mar 98 14:13:17 -0600 Received: from UITVM1 by vnet.IBM.COM (IBM VM SMTP V2R4) with BSMTP id 8389; Thu, 12 Mar 98 15:13:13 EST Date: Thu, 12 Mar 98 21:14:20 CET From: "Bert Wijnen" To: rpresuhn@dorothy.peer.com, agentx@peer.com Subject: agentx credential delivery Ref: Your note of Thu, 12 Mar 1998 11:42:29 -0800 (PST) Subject: agentx credential delivery Randy writes: > Consider: > > | +--------------------------------------------------------+ > |(snmp) |(local) | > | V +----------------------+ | > | +----------------------------+ | disman subagent: | | > | +------+ +-------------+ |expression | Command |---+ > +->| SNMP | Engine| Master Agent| Agentx /| MIB | generator| > |iface | | Interface |--------< +----------------------+ > +------+ +-------------+ Protocol\ > +----------------------------+ \+-------------------+ > | other subagents | > +-------------------+ > > AgentX only describes the subagent/master agent interface. It does > not describe the command generator/snmp engine interface. > >> I think AgentX is fine. We know that AgentX is not designed to handle >> all possible cases on earth. > > I think almost all of us agree on the last point. The question is whether > the sort of "ownership" information required at the command responder > interface should percolate all the way out to the subagent interface. > The disman and rmon mibs suggest that it should, though it DOES bother me. > I think passing securityModel, securityLevel and securityName is kind of OK. The subagents can use that for example to do various things based on if something was received secure or not. What would bother me too is that if such a subagent could go back to the engine via "(local)" as depicted above and then be able to use the credentials of securityName without having to specify any password or key or whatever.... that seems like a backdoor. Bert From rpresuhn@dorothy.peer.com Thu Mar 12 14:36:16 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id OAA23412 for ; Thu, 12 Mar 1998 14:36:16 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA23086 for ; Thu, 12 Mar 1998 14:35:37 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma022854; Thu, 12 Mar 98 14:34:32 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA26132 for ; Thu, 12 Mar 1998 14:34:16 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma025609; Thu, 12 Mar 98 14:33:47 -0600 Received: (from rpresuhn@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id MAA09729 for agentx@peer.com; Thu, 12 Mar 1998 12:28:32 -0800 (PST) Date: Thu, 12 Mar 1998 12:28:32 -0800 (PST) From: Randy Presuhn Message-Id: <199803122028.MAA09729@dorothy.peer.com> To: agentx@peer.com Subject: Re: agentx credential delivery Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > To: Randy Presuhn > Cc: agentx@peer.com > Subject: Re: agentx credential delivery > Date: Thu, 12 Mar 98 14:49:45 -0500 > From: Mike Daniele > > Randy, > > >> If this is correct, is there some reason the MIB can't simply > >> define objects to contain this required information? > > >No. The architecture defined in RFC 2271 supports the flow of this > >information to a "command responder" via the processPdu abstract service > >interface described in clause 4.1.2 of RFC 2271. > > What I was asking is, why can't the manager application pass > whatever is needed to perform a request, within the variable bindings > in the request? Ah. This is actually what I would have liked to have seen in the expression mib. It works with agentx. The "gotcha" with this approach shows up when it comes to scripting; it effectively makes all execution "setuid" to whatever the stored credentials are. This isn't necessarily all THAT bad when lanchers and scripts are properly separated. > >Where we run into trouble is the requirement to store this information > >(not directly accessible via management protocol) in a disman expression > >mib... > > Why isn't it accessible via management protocol? My preference would be to see it carried in management protocol. The editor of the script MIB sees it differently. I have not seen a clear consensus on this issue in the disman working group yet. > >It bothers me too, BUT... > >The SNMP architecture does not define the agent/subagent abstract > >service interface. It DOES define the the abstract service > >interface to a command responder. One way of looking at it is this: > > Unrelated to AgentX (but I'll discuss it here anyway :-), I think > this is oversimplifying. > > >= processPdu( -- process Request/Notification PDU > >= IN messageProcessingModel -- typically, SNMP version > >= IN securityModel -- Security Model in use > >= IN securityName -- on behalf of this principal > >= IN securityLevel -- Level of Security > >= IN contextEngineID -- data from/at this SNMP entity > >= IN contextName -- data from/in this context > >= IN pduVersion -- the version of the PDU > >= IN PDU -- SNMP Protocol Data Unit > >= IN maxSizeResponseScopedPDU -- maximum size of the Response PDU > >= IN stateReference -- reference to state information > > > > Note that the PDU is separate from the security information. > > RFC 2273 says (under Command Responder Applications): > > (5) The management operation represented by the SNMPv2 operation type > is performed with respect to the relevant MIB view within the > context named by the contextName, according to the procedures set > forth in [RFC1905]. The relevant MIB view is determined by the > securityLevel, securityModel, contextName, securityName, and SNMPv2 > operation type. To determine whether a particular object instance > is within the relevant MIB view, the following abstract service > interface is called: > > statusInformation = -- success or errorIndication > isAccessAllowed( > IN securityModel -- Security Model in use > IN securityName -- principal who wants to access > IN securityLevel -- Level of Security > IN viewType -- read, write, or notify view > IN contextName -- context containing variableName > IN variableName -- OID for the managed object > ) > > Although not specifically stated, it seems obvious that the > security information is here solely for determining if the > variableName is within view. That is certainly the way I was thinking about it when we were working on the architecture. However, the working group did not want to get into the detail issues of, for example, defining the subagent abstract service interface, so we put no qualifications on what the command responder might do with these tidbits. > RFC 1905 defines variable binding validation, and > creation/value assignment, only in terms of what is passed in > the PDU. > > So I think an argument could be made that it (disman) violates > the SNMP architecture (as a whole, not just RFC 2271). > > Whether it does or not, it certainly seems to violate > any sense of propriety :-) Modular design, layering, that > kind of thing. As I've said before, it "bothers" me too. However, I haven't seen the "killer" argument or overwhelming consensus to say that the information HAS to be carried in management protocol rather. However, folks have been doing this kind of thing for a long time. For example, check out RFC 1757 page 34 in the DESCRIPTION of alarmVariable. > As to AgentX: > > >>Unfortunately, RFC 2257 doesn't give us a way to deliver the > >>securityModel, securityName, and securityLevel information > >>this application will need as a command generator. > > >Any thoughts on how one might extend AgentX to deliver these three > >pieces of information? > > If it's delivered at all, it would invalidate section 9 item 2 > of RFC 2257, wouldn't it? | 2. During an AgentX session, is any SNMP security-related | information (for example, community names) passed from the | master agent to the subagent? ... In the context of these rest of section 9, one would have to clarify this point to say that it doesn't leak secrets. The rest of section 9 really has to do with the security of the agent/subagent connection and the level of trust afforded subagents, and whether the triple is carried in protocol really doesn't change the reasoning in that section. -------------------------- NEW ADDRESS! ------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From rpresuhn@dorothy.peer.com Thu Mar 12 14:51:47 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id OAA23616 for ; Thu, 12 Mar 1998 14:51:46 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA25102 for ; Thu, 12 Mar 1998 14:51:08 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma024820; Thu, 12 Mar 98 14:50:18 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA12839 for ; Thu, 12 Mar 1998 14:50:03 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma012480; Thu, 12 Mar 98 14:49:43 -0600 Received: (from rpresuhn@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id MAA10244 for agentx@peer.com; Thu, 12 Mar 1998 12:44:23 -0800 (PST) Date: Thu, 12 Mar 1998 12:44:23 -0800 (PST) From: Randy Presuhn Message-Id: <199803122044.MAA10244@dorothy.peer.com> To: agentx@peer.com Subject: Re: agentx credential delivery Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > Date: Thu, 12 Mar 98 21:14:20 CET > From: "Bert Wijnen" > To: rpresuhn@dorothy.peer.com, agentx@peer.com > Subject: agentx credential delivery ... > I think passing securityModel, securityLevel and securityName is kind > of OK. That ringing endorsement is about as far as I've been able to bring myself. I doubt I'll ever be more comfortable with the idea than "kind of OK". It sounds others have similar misgivings. > The subagents can use that for example to do various things > based on if something was received secure or not. > What would bother me too is that if such a subagent could go > back to the engine via "(local)" as depicted above and then be able to > use the credentials of securityName without having to specify any > password or key or whatever.... that seems like a backdoor. ... This gets back to the discussions at the snmpv3 interim meetings regarding how applications fit into the trust model and how they authenticated themselves to the engine. As I recall, we punted on that one, saying it was an API issue rather than an ASI issue. -------------------------- NEW ADDRESS! ------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From daniele@zk3.dec.com Thu Mar 12 15:27:40 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id PAA24092 for ; Thu, 12 Mar 1998 15:27:40 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA28221 for ; Thu, 12 Mar 1998 15:27:01 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma027949; Thu, 12 Mar 98 15:26:10 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id PAA20324 for ; Thu, 12 Mar 1998 15:25:55 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma019901; Thu, 12 Mar 98 15:25:35 -0600 Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA14156; Thu, 12 Mar 1998 13:20:31 -0800 (PST) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id PAA20404; Thu, 12 Mar 1998 15:20:29 -0600 (CST) Received: from mail11.digital.com(192.208.46.10) by cashew.bmc.com via smap (V2.0) id xma020391; Thu, 12 Mar 98 15:20:13 -0600 Received: from flume.zk3.dec.com (flume.zk3.dec.com [16.140.112.3]) by mail11.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id QAA06134; Thu, 12 Mar 1998 16:20:11 -0500 (EST) Received: from bernie.zk3.dec.com by flume.zk3.dec.com (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA24259; Thu, 12 Mar 1998 16:20:07 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA32180; Thu, 12 Mar 1998 16:17:36 -0500 Message-Id: <9803122117.AA32180@bernie.zk3.dec.com> To: Randy Presuhn Cc: agentx@peer.com Subject: Re: agentx credential delivery In-Reply-To: Your message of "Thu, 12 Mar 98 12:28:32 PST." <199803122028.MAA09729@dorothy.peer.com> Date: Thu, 12 Mar 98 16:17:36 -0500 From: Mike Daniele X-Mts: smtp >Unfortunately, RFC 2257 doesn't give us a way to deliver the >securityModel, securityName, and securityLevel information >this application will need as a command generator. Does this mean that the disman MIBs require the agent to implement SNMPv3? Mike From rpresuhn@dorothy.peer.com Thu Mar 12 16:53:29 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id QAA25237 for ; Thu, 12 Mar 1998 16:53:28 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA03841 for ; Thu, 12 Mar 1998 16:52:49 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma003539; Thu, 12 Mar 98 16:51:29 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA19320 for ; Thu, 12 Mar 1998 16:51:12 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma018992; Thu, 12 Mar 98 16:50:59 -0600 Received: (from rpresuhn@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id OAA22732 for agentx@peer.com; Thu, 12 Mar 1998 14:45:33 -0800 (PST) Date: Thu, 12 Mar 1998 14:45:33 -0800 (PST) From: Randy Presuhn Message-Id: <199803122245.OAA22732@dorothy.peer.com> To: agentx@peer.com Subject: Re: agentx credential delivery Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > To: Randy Presuhn > Cc: agentx@peer.com > Subject: Re: agentx credential delivery > Date: Thu, 12 Mar 98 16:17:36 -0500 > From: Mike Daniele > > >Unfortunately, RFC 2257 doesn't give us a way to deliver the > >securityModel, securityName, and securityLevel information > >this application will need as a command generator. > > Does this mean that the disman MIBs require the agent > to implement SNMPv3? > > Mike I hope not. As far as I know, there are no requirements or intention to tie the disman MIBs to SNMPv3. The notions of command generator and the ASIs belong to the architecture, and are intended to be SNMP version-neutral. However, the kinds of things that are possible with delegation strongly suggest that a prudent administrator would deploy disman implementations only in environments with appropriate authentication and access control infrastructure. :-) In a pure SNMPv1 environment, an expression MIB still needs to have some notion of whose behalf it's acting on. Whether that environment's access control model is VACM or something else is a separate issue. RFC 1757 gives a good look at one way people have thought about this from the perspective of non-SNMPv3 implementations. The community MIB discussion on the snmpv3@tis.com mailing list illustrates how the mappings could work in a multi-protocol engine. -------------------------- NEW ADDRESS! ------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From schoenw@ibr.cs.tu-bs.de Tue Mar 17 11:40:54 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id LAA24347 for ; Tue, 17 Mar 1998 11:40:54 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA19286 for ; Tue, 17 Mar 1998 11:40:08 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma018981; Tue, 17 Mar 98 11:38:55 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA25368 for ; Tue, 17 Mar 1998 11:39:18 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma024922; Tue, 17 Mar 98 11:38:48 -0600 Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA01984 for ; Tue, 17 Mar 1998 09:27:40 -0800 (PST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA17417 for ; Tue, 17 Mar 1998 11:26:55 -0600 (CST) Received: from ra.ibr.cs.tu-bs.de(134.169.34.12) by almond.bmc.com via smap (V2.0) id xma017379; Tue, 17 Mar 98 11:26:30 -0600 Received: from henkell.ibr.cs.tu-bs.de (henkell [134.169.34.191]) by ra.ibr.cs.tu-bs.de (8.8.6/8.8.6) with ESMTP id SAA14486; Tue, 17 Mar 1998 18:27:07 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id SAA16103; Tue, 17 Mar 1998 18:27:05 +0100 Date: Tue, 17 Mar 1998 18:27:05 +0100 Message-Id: <199803171727.SAA16103@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: sgudur@hotmail.com CC: agentx@peer.com Subject: Indexing structure in the AgentX MIB The AgentX MIB has three tables: 1) agentxConnectionTable 2) agentxSessionTable 3) agentxRegistrationTable There is a 1:n relationship between 1) and 2) and another 1:n relationship between 2) and 3). Further, every session is bound to a single connection and every registration is bound to a single session. This means that the relationships between the tables can be modeled by the indexing structure (a): agentxConnectionTable INDEX { agentxConnIndex } agentxSessionTable INDEX { agentxConnIndex, agentxSessionIndex } agentxRegistrationTable INDEX { agentxConnIndex, agentxSessionIndex, agentxRegIndex } The draft of the AgentX MIB uses a different approach (b). Every table has a single index and there is a column agentxSessionConnIndex in the agentxSessionTable which points to the agentxConnectionTable. There is also a column agentxRegSessionIndex in the agentxRegistrationTable which points back to the agentxSessionTable. I think approach (a) has nice properties: First, you can use the natural order to easily get all registrations for a given session or all sessions on a given connection. Second, you don't need to make additional lookups if you want to know the connection associated with a given registration. Third, you save two columns. Finally, it simplifies the description of some object types (e.g. agentxRegStart and agentxRegEnd) because the subagent is implicitely identified by the instance identifier. Of course, the cost of approach (a) is that each instance identifier gets two more components, which means at least 2 additional bytes per instance identifier. Approach (b) does not lead to a natural sorting order, which means that in most cases the complete tables have to be read in order to get e.g. all registrations for a given session. Are there any reasons for choosing approach (b)? Juergen -- Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3283) From bnatale@acecomm.com Tue Mar 17 12:14:03 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id MAA24795 for ; Tue, 17 Mar 1998 12:14:02 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA22123 for ; Tue, 17 Mar 1998 12:13:18 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma021966; Tue, 17 Mar 98 12:12:40 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA22791 for ; Tue, 17 Mar 1998 12:13:04 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma022325; Tue, 17 Mar 98 12:12:33 -0600 Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA03615 for ; Tue, 17 Mar 1998 10:06:56 -0800 (PST) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id MAA26365 for ; Tue, 17 Mar 1998 12:06:56 -0600 (CST) Received: from relay1.smtp.psi.net(38.8.14.2) by cashew.bmc.com via smap (V2.0) id xma026346; Tue, 17 Mar 98 12:06:25 -0600 Received: from nips.acec.com by relay1.smtp.psi.net (8.8.5/SMI-5.4-PSI) id NAA16603; Tue, 17 Mar 1998 13:05:26 -0500 (EST) Received: from bnatale by nips.acec.com (5.65/3.2.083191-ACE*COMM) id AA00870; Tue, 17 Mar 1998 13:05:04 -0500 Message-Id: <3.0.5.32.19980317130838.0096d660@nips.acecomm.com> X-Sender: natale@nips.acecomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 17 Mar 1998 13:08:38 -0500 To: Juergen Schoenwaelder From: Bob Natale Subject: Re: Indexing structure in the AgentX MIB Cc: sgudur@hotmail.com, agentx@peer.com In-Reply-To: <199803171727.SAA16103@henkell.ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 06:27 PM 3/17/98 +0100, Juergen Schoenwaelder wrote: Hi Juergen, >The AgentX MIB For the record, Smitha is due to post a revised MIB for review, discussion, and revision, in the immediate future. <...comparison of two indexing schemes...> >I think approach (a) has nice properties: Agreed. <...> >Of course, the cost of approach (a) is that each instance >identifier gets two more components, which means at >least 2 additional bytes per instance identifier. Seems a fair price to pay for the benefits received. >Approach (b) does not lead to a natural sorting order, which >means that in most cases the complete tables have to be read >in order to get e.g. all registrations for a given session. Would like to avoid that, but... >Are there any reasons for choosing approach (b)? It may just be the result of the "-01" status of the MIB and the fact that expected use of this MIB--while important and potentially very useful when needed--may be fairly limited. Of course, that latter point is no justification for not selecting a better design alternative, given acceptable cost. Let's pursue Juegen's suggestion in detail based on the "-02" draft of the MIB coming soon from Smitha. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ---- WinSNMP DLL, SDK, Apps & Agents for Win16/32 & UNIX ---- ------ NetPlus (r) "FCAPS" Telemanagement Applications ------ From rpresuhn@dorothy.peer.com Tue Mar 17 12:33:05 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id MAA25048 for ; Tue, 17 Mar 1998 12:33:05 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA24325 for ; Tue, 17 Mar 1998 12:32:20 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma024137; Tue, 17 Mar 98 12:31:23 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA09002 for ; Tue, 17 Mar 1998 12:31:46 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma008686; Tue, 17 Mar 98 12:31:29 -0600 Received: (from rpresuhn@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id KAA03841 for agentx@peer.com; Tue, 17 Mar 1998 10:25:47 -0800 (PST) Date: Tue, 17 Mar 1998 10:25:47 -0800 (PST) From: Randy Presuhn Message-Id: <199803171825.KAA03841@dorothy.peer.com> To: agentx@peer.com Subject: Re: Indexing structure in the AgentX MIB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > Date: Tue, 17 Mar 1998 13:08:38 -0500 > To: Juergen Schoenwaelder > From: Bob Natale > Subject: Re: Indexing structure in the AgentX MIB > Cc: sgudur@hotmail.com, agentx@peer.com > > >At 06:27 PM 3/17/98 +0100, Juergen Schoenwaelder wrote: > > Hi Juergen, > > >The AgentX MIB > > For the record, Smitha is due to post a revised MIB for > review, discussion, and revision, in the immediate > future. > > <...comparison of two indexing schemes...> > >I think approach (a) has nice properties: > > Agreed. ... Agreed. As I recall the discussions from the agentx list last November/ December, this was the direction the group was headed. -------------------------- NEW ADDRESS! ------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From Sharon.Azulai@conduct.com Fri Mar 20 11:03:30 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id LAA22267 for ; Fri, 20 Mar 1998 11:03:29 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA24354 for ; Fri, 20 Mar 1998 11:02:48 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma024054; Fri, 20 Mar 98 11:01:52 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA29527 for ; Fri, 20 Mar 1998 11:02:14 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma029176; Fri, 20 Mar 98 11:01:57 -0600 Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA07725 for ; Fri, 20 Mar 1998 08:50:03 -0800 (PST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA22362 for ; Fri, 20 Mar 1998 10:49:20 -0600 (CST) Received: from silver.conduct.com(192.216.104.4) by almond.bmc.com via smap (V2.0) id xma022351; Fri, 20 Mar 98 10:49:19 -0600 Received: from conduct.com (gold [192.216.104.5]) by silver.conduct.com (8.7.5/8.6.12) with ESMTP id IAA05629 for ; Fri, 20 Mar 1998 08:49:45 -0800 (PST) Message-ID: <351346D1.154368EC@conduct.com> Date: Fri, 20 Mar 1998 20:49:21 -0800 From: Sharon Azulai X-Mailer: Mozilla 4.04 [en]C-DIAL (WinNT; I) MIME-Version: 1.0 To: agentx@peer.com Subject: subscribe Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: base64 oA0KDQo= From sgudur@hotmail.com Mon Mar 23 17:48:21 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id RAA08848 for ; Mon, 23 Mar 1998 17:48:21 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA09374 for ; Mon, 23 Mar 1998 17:48:15 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma009173; Mon, 23 Mar 98 17:47:32 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA08160 for ; Mon, 23 Mar 1998 17:47:13 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma007893; Mon, 23 Mar 98 17:46:55 -0600 Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id PAA06297 for ; Mon, 23 Mar 1998 15:31:55 -0800 (PST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA07456 for ; Mon, 23 Mar 1998 17:31:53 -0600 (CST) Received: from f80.hotmail.com(207.82.250.186) by almond.bmc.com via smap (V2.0) id xma007442; Mon, 23 Mar 98 17:31:27 -0600 Received: (qmail 3627 invoked by uid 0); 23 Mar 1998 23:31:25 -0000 Message-ID: <19980323233125.3626.qmail@hotmail.com> Received: from 152.67.249.57 by www.hotmail.com with HTTP; Mon, 23 Mar 1998 15:31:24 PST X-Originating-IP: [152.67.249.57] From: "Smitha Gudur" To: agentx@peer.com Subject: draft-ietf-agentx-mib-02.txt Content-Type: multipart/mixed; boundary="====================987654321_0==_" Date: Mon, 23 Mar 1998 15:31:24 PST --====================987654321_0==_ Content-Type: text/plain; charset="us-ascii" ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com --====================987654321_0==_ Content-Type: text/plain; name="readme3.txt" Content-Disposition: attachment; filename="readme3.txt" This is a posting of revised AgentX MIB. The revisions are made based on the inputs received from mailing list. This has been changed accordingly. The following changes are made to this draft: Added TruthValue textual convention. Added agentxRegInstance to agentxRegistrationEntry. This indicates whether the registration is an instance registration or not an instance registration. Removed agentxSessionConnIndex from session entry. Removed agentxRegSessionIndex from registration entry. agentxSessionEntry is now indexed by agentxConnIndex and agentxSessionIndex. agentxRegistrationEntry is indexed by agentxConnIndex, agentxSessionIndex and agentxRegIndex. Please send questions, comments and suggested changes on this MIB to the list (agentx@peer.com). Thanks Smitha Gudur INTERNET-DRAFT M. Greene Xedia. S. Gudur BMC Software, Inc. 23 March 1998 Definitions of Managed Objects for Extensible SNMP Agents | Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as a "work in progress". To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects managing SNMP agents that use the Agent Extensibility (AgentX) Protocol. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. This memo does not specify a standard for the Internet community. AgentX Working Group Expires September 1998 [Page 1] Internet Draft AgentX MIB 23 March 1998 1. The SNMP Network Management Framework The SNMP Network Management Framework presently consists of three major components. They are: - the SMI, described in RFC 1902 [1] - the mechanisms used for describing and naming objects for the purpose of management. - the MIB-II, STD 17, RFC 1213 [2] - the core set of managed objects for the Internet suite of protocols. - the protocol, RFC 1157 [3] and/or RFC 1905 [4], - the protocol for accessing managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 1.1. Object Definitions Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. In particular, each object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the descriptor, to also refer to the object type. 2. Introduction The SNMP Agent Extensibility Protocol (AgentX) is a protocol used to distribute the implementation of an SNMP agent amongst a single "master agent" and multiple "subagents". See [5] for details about the AgentX protocol. The goals of the AgentX MIB are: - List the set of subagents that currently have logical sessions open with the master agent. - Identify each subagent's type, vendor, transport address, AgentX protocol version, and other characteristics. - Identify the set of MIB objects each subagent implements, the context in which the objects are registered, and the priority of the registration. AgentX Working Group Expires September 1998 [Page 2] Internet Draft AgentX MIB 23 March 1998 - Provide statistics about the protocol operation such as the number of packets to and from each subagent. - Determine protocol operational parameters such as the timeout interval for responses from a subagent and the priority at which a subagent registers a particular MIB region. - Allow (but do not require) managers to be able to modify AgentX protocol operational parameters and to explicitly close subagent sessions with the master agent. 3. Overview This MIB is organized into four groups. The agentxGeneral group provides information describing the master agent's Agentx support, including the protocol version supported and the supported transport mechanisms. The agentxConnection group provides information describing the current set of connections capable of carrying Agentx sessions. The agentxSession group provides information describing the current set of AgentX sessions. The agentxRegistration group provides information describing the current set of registrations. Three tables form the heart of this mib. These are the connection, session, and registration tables. Entries in the registration table exist in a many-to-one relationship with entries in the session table. This relationship is represented through the agentxSessionIndex and agentxConnIndex. Registration entries are indexed by agentxConnIndex and agentxSessionIndex, to determine which registration(s), a subagent session is responsible for a given connection. Entries in the session table exist in a many-to-one relationship with entries in the connection table. This relationship is represented through the agentxConnIndex in a session table. Session entries are indexed by agentxConnIndex to determine which sessions(s), are carried by a given connection. AgentX Working Group Expires September 1998 [Page 3] Internet Draft AgentX MIB 23 March 1998 4. Definitions AGENTX-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, experimental, Counter32, Gauge32, Unsigned32 FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF TEXTUAL-CONVENTION, TimeStamp, TruthValue | FROM SNMPv2-TC; agentxMIB MODULE-IDENTITY LAST-UPDATED "9803231200Z" -- Mar 23, 1998 | ORGANIZATION "IETF AgentX Working Group" CONTACT-INFO "WG-email: agentx@peer.com | Subscribe: agentx-request@peer.com | http://www.ietf.org/html.charters/agentx-charter.html Chair: Bob Natale ACE*COMM Corporation Email: bnatale@acec.com Editor: Smitha Gudur BMC Software, Inc. 965 Stewart Drive | Sunnyvale, CA 94086 | Phone: +1 408-616-3100 | Email: sgudur@bmc.com " DESCRIPTION "This is the MIB module for the SNMP Agent Extensibility Protocol (AgentX). This MIB module will be implemented by the master agent." -- For testing purposes only. Need to get an experimental id ::= { experimental 2001 } agentxObjects OBJECT IDENTIFIER ::= { agentxMIB 1 } -- -- Define the four groups that serve to organize the -- objects in this MIB -- agentxGeneral OBJECT IDENTIFIER ::= { agentxObjects 1 } agentxConnection OBJECT IDENTIFIER ::= { agentxObjects 2 } AgentX Working Group Expires September 1998 [Page 4] Internet Draft AgentX MIB 23 March 1998 agentxSession OBJECT IDENTIFIER ::= { agentxObjects 3 } agentxRegistration OBJECT IDENTIFIER ::= { agentxObjects 4 } -- -- Textual Conventions -- Utf8String ::= TEXTUAL-CONVENTION DISPLAY-HINT "255a" STATUS current DESCRIPTION "To facilitate internationalization, this TC represents information taken from the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 character encoding scheme described in RFC 2044 [8]. For strings in 7-bit US-ASCII, there is no impact since the UTF-8 representation is identical to the US-ASCII encoding." SYNTAX OCTET STRING (SIZE (0..255)) agentxDefaultTimeout OBJECT-TYPE SYNTAX INTEGER (0..255) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The default length of time, in seconds, that the master agent should allow to elapse after dispatching a message to a subagent before it regards the subagent as not responding. This is a system-wide value that may be overridden by the values associated with a particular subagent (agentxSessionTimeout) or a particular registered MIB region (agentxRegTimeout)." DEFVAL { 5 } ::= { agentxGeneral 1 } agentxMasterAgentXVer OBJECT-TYPE SYNTAX INTEGER (1..256) MAX-ACCESS read-only STATUS current DESCRIPTION "The AgentX protocol version supported by this master agent. Current version is 1. Note that the master agent must allow registration of earlier version subagents." DEFVAL { 1 } ::= { agentxGeneral 2 } agentxMasterTransports OBJECT-TYPE SYNTAX BITS { unixDomainSockets(0), tcp(1), AgentX Working Group Expires September 1998 [Page 5] Internet Draft AgentX MIB 23 March 1998 udp(2), sharedMem(3), other(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The transports that the master agent supports." DEFVAL { { tcp } } ::= { agentxGeneral 3 } -- -- The Agentx Subagent Connection Group -- agentxConnTableLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the last row creation or deletion occurred in the agentxConnectionTable." ::= { agentxConnection 1 } agentxConnNumber OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of entries in the agentxConnectionTable. Note that this may be smaller than the largest value of agentxConnIndex since index values are not reused when entries come and go from the agentxConnectionTable." ::= { agentxConnection 2 } agentxConnectionTable OBJECT-TYPE SYNTAX SEQUENCE OF AgentxConnectionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The agentxConnectionTable tracks all current Agentx transport connections. There may be zero, one, or more agentx sessions on a given Agentx connection." ::= { agentxConnection 3 } AgentxConnectionEntry ::= SEQUENCE { agentxConnIndex Unsigned32, agentxConnOpenTime TimeStamp, agentxConnTransportType INTEGER, AgentX Working Group Expires September 1998 [Page 6] Internet Draft AgentX MIB 23 March 1998 agentxConnTransportAddr OCTET STRING, agentxConnSessions Gauge32 } agentxConnectionEntry OBJECT-TYPE SYNTAX AgentxConnectionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An agentxConnectionEntry contains information describing a single Agentx transport connection. A connection may be used to support zero or more Agentx sessions. Entries come into being when the transport connection is established, and are not deleted unless the transport connection has been terminated." INDEX { agentxConnIndex } ::= { agentxConnectionTable 1 } agentxConnIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of agentxConnIndex uniquely identifies each open transport connection used by this master agent to provide AgentX service. Values of this index should not be re-used. The value assigned to a given transport connection is constant for the lifetime of that connection." ::= { agentxConnectionEntry 1 } agentxConnOpenTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this connection was established and, therefore, its value when this entry was added to the table." ::= { agentxConnectionEntry 2 } agentxConnTransportType OBJECT-TYPE SYNTAX INTEGER { unixDomainSockets(1), tcp(2), udp(3), sharedMem(4), other(5) } MAX-ACCESS read-only STATUS current DESCRIPTION AgentX Working Group Expires September 1998 [Page 7] Internet Draft AgentX MIB 23 March 1998 "The transport protocol in use for this connection to the master agent. This information can be used by a management application to determine how agentxConnTransportAddr should be displayed." ::= { agentxConnectionEntry 3 } agentxConnTransportAddr OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The transport address of the remote (subagent) end of this connection to the master agent, in network byte order. Management applications can use agentxConnTransportType to determine how this information is to be formatted for display." ::= { agentxConnectionEntry 4 } agentxConnSessions OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of AgentX sessions being carried by this transport connection. For purposes of this MIB, an AgentX session begins when a valid agentx-Open-PDU is received, and ends when a corresponding agentx-Close-PDU has been sent or received by the master agent." ::= { agentxConnectionEntry 5 } -- -- The AgentX Subagent Session Group -- agentxSessionTableLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the last row creation or deletion occurred in the agentxSessionTable." ::= { agentxSession 1 } agentxSessionNumber OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of entries in the AgentX Working Group Expires September 1998 [Page 8] Internet Draft AgentX MIB 23 March 1998 agentxSessionTable. Note that this may be smaller than the largest value of agentxSessionIndex since index | values are not reused when entries come and go from the agentxSessionTable." ::= { agentxSession 2 } -- -- The AgentX Subagent Session Table -- agentxSessionTable OBJECT-TYPE SYNTAX SEQUENCE OF AgentxSubagentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of AgentX subagents that have open sessions with the AgentX master agent." ::= { agentxSession 3 } agentxSessionEntry OBJECT-TYPE SYNTAX AgentxSubagentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single open session between the AgentX master agent and a subagent." INDEX { agentxConnIndex, agentxSessionIndex } | ::= { agentxSessionTable 1 } AgentxSubagentEntry ::= SEQUENCE { agentxSessionIndex Unsigned32, agentxSessionObjectID OBJECT IDENTIFIER, agentxSessionDescr Utf8String, agentxSessionAdminStatus INTEGER, agentxSessionOpenTime TimeStamp, agentxSessionAgentXVer INTEGER, agentxSessionTimeout INTEGER } agentxSessionIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index for the subagent session. Note that if a subagent's session with the master agent is closed for any reason its index should not be re-used, therefore, the values of agentxSessionIndex may not be contiguous and will generally not be the same for the same subagent AgentX Working Group Expires September 1998 [Page 9] Internet Draft AgentX MIB 23 March 1998 across multiple sessions. Index values assigned for a given registration are constant for the lifetime of this table." ::= { agentxSessionEntry 1 } agentxSessionObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "This is analogous to sysObjectID defined in MIB-2 [2] and is taken from the o.id field of the agentx-Open-PDU." ::= { agentxSessionEntry 2 } -- -- Issue: should we describe this more in terms of AGENT-CAPABILITIES -- or sysORTable? -- agentxSessionDescr OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "A textual description of the subagent. This is analogous to sysDescr defined in MIB-2 [2] and is taken from the o.descr field of the agentx-Open-PDU." ::= { agentxSessionEntry 3 } agentxSessionAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The administrative (desired) status of the subagent. Setting the value to 'down(2)' closes the subagent session (with c.reason set to 'reasonByManager'). When read, the value returned is always 'up(1)'." DEFVAL { up } ::= { agentxSessionEntry 4 } agentxSessionOpenTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION AgentX Working Group Expires September 1998 [Page 10] Internet Draft AgentX MIB 23 March 1998 "The value of sysUpTime when this session was opened and, therefore, its value when this entry was added to the table." ::= { agentxSessionEntry 5 } agentxSessionAgentXVer OBJECT-TYPE SYNTAX INTEGER (1..256) MAX-ACCESS read-only STATUS current DESCRIPTION "The version of the AgentX protocol supported by the subagent. This will be less than or equal to the value of agentxMasterAgentXVer." DEFVAL { 1 } ::= { agentxSessionEntry 6 } agentxSessionTimeout OBJECT-TYPE SYNTAX INTEGER (0..255) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The length of time, in seconds, that a master agent should allow to elapse after dispatching a message to this subagent before it regards the subagent as not responding. This value is taken from the o.timeout field of the agentx-Open-PDU. This is a subagent-specific value that may be overridden by values associated with specific registered MIB regions (see agentxRegTimeout). The default value of '0' indicates that the master agent's default timeout value should be used (see agentxDefaultTimeout)." DEFVAL { 0 } ::= { agentxSessionEntry 7 } -- -- The AgentX Registration Information group -- -- The statistics in this group are maintained by the Master Agent. -- -- Other stats have been removed. Support trap generation based -- on certain situations for duplicate registration. -- agentxRegisterDuplicate OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Response-PDU messages sent by this master AgentX Working Group Expires September 1998 [Page 11] Internet Draft AgentX MIB 23 March 1998 agent where the res.error field was set to 'duplicateRegistration'." ::= { agentxRegistration 1 } -- -- The AgentX Registration Table -- agentxRegistrationTable OBJECT-TYPE SYNTAX SEQUENCE OF AgentxRegistrationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of registered OBJECT IDENTIFIER regions. This is the table used to identify a registered region of a subagent. Note that a subagent registration may be broken up into multiple entries in this table, as described in the AgentX Protocol specification [5]." ::= { agentxRegistration 2 } agentxRegistrationEntry OBJECT-TYPE SYNTAX AgentxRegistrationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A single registered region. Regions are added by the master agent when subagents register and are removed from the table when the subagents unregister the region or their sessions are closed. Note that the combination of agentxRegContext, agentxRegStart and agentxRegDispatchOrder will be unique and could have been used for indexing purposes, but would have potentially resulted in excessively long OBJECT IDENTIFIERs." INDEX { agentxConnIndex, agentxSessionIndex, agentxRegIndex } | ::= { agentxRegistrationTable 1 } AgentxRegistrationEntry ::= SEQUENCE { agentxRegIndex Unsigned32, agentxRegContext OCTET STRING, agentxRegStart OBJECT IDENTIFIER, agentxRegEnd OBJECT IDENTIFIER, agentxRegPriority Unsigned32, agentxRegTimeout INTEGER, agentxRegInstance TruthValue | } agentxRegIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current AgentX Working Group Expires September 1998 [Page 12] Internet Draft AgentX MIB 23 March 1998 DESCRIPTION "AgentxRegIndex is an integer that uniquely identifies a registration entry. Its value is constant for the lifetime of an entry." ::= { agentxRegistrationEntry 1 } agentxRegContext OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The context in which the subagent supports the objects in this region. A zero-length context indicates the default context." ::= { agentxRegistrationEntry 2 } agentxRegStart OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The starting OBJECT IDENTIFIER of this registration entry. The subagent identified by agentxSessionIndex implements objects | starting at this value (inclusive). Note that this value could identify an object type, an object instance, or a partial object instance." ::= { agentxRegistrationEntry 3 } agentxRegEnd OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The ending OBJECT IDENTIFIER of this registration entry. The subagent identified by agentxSessionIndex implements objects up to but not including this value. Note that this value could identify an object type, an object instance, or a partial object instance." ::= { agentxRegistrationEntry 4 } -- -- To support other subagent types that can be visible -- to the manager. -- agentxRegPriority OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION AgentX Working Group Expires September 1998 [Page 13] Internet Draft AgentX MIB 23 March 1998 "The subagent's priority when exporting this OID range. Lower values have higher priority." DEFVAL { 255 } ::= { agentxRegistrationEntry 5 } agentxRegTimeout OBJECT-TYPE SYNTAX INTEGER (0..255) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The timeout value, in seconds, for subagent responses to requests associated with this OID range. The value '0' indicates that the default value (indicated by agentxSessionTimeout or agentxDefaultTimeout) is to be used. This value is taken from the r.timeout field of the agentx-Register-PDU." DEFVAL { 0 } ::= { agentxRegistrationEntry 7 } agentxRegInstance OBJECT-TYPE | SYNTAX TruthValue | MAX-ACCESS read-only | STATUS current | DESCRIPTION | "The value of agentxRegInstance is `true' for | registrations for which the INSTANCE_REGISTRATION | was set, and is `false' for all other registrations." | DEFVAL { false } | ::= { agentxRegistrationEntry 8 } | -- -- Conformance Statements for the AgentX MIB -- agentxConformance OBJECT IDENTIFIER ::= { agentxMIB 2 } agentxMIBGroups OBJECT IDENTIFIER ::= { agentxConformance 1 } agentxMIBCompliances OBJECT IDENTIFIER ::= { agentxConformance 2 } agentxMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the AgentX protocol. Note that a compliant agent can implement all objects in this MIB module as read-only." MODULE -- this module MANDATORY-GROUPS { agentxMIBGroup } AgentX Working Group Expires September 1998 [Page 14] Internet Draft AgentX MIB 23 March 1998 OBJECT agentxDefaultTimeout MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT agentxSessionAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { agentxMIBCompliances 1 } agentxMIBGroup OBJECT-GROUP OBJECTS { agentxDefaultTimeout, agentxMasterAgentXVer, agentxMasterTransports, agentxConnTableLastChange, agentxConnNumber, agentxConnOpenTime, agentxConnTransportType, agentxConnTransportAddr, agentxConnSessions, agentxSessionTableLastChange, agentxSessionNumber, agentxSessionTimeout, agentxSessionObjectID, agentxSessionDescr, agentxSessionAdminStatus, agentxSessionOpenTime, agentxSessionAgentXVer, agentxRegisterDuplicate, agentxRegContext, agentxRegStart, agentxRegEnd, agentxRegPriority, agentxRegTimeout, agentxRegInstance | } STATUS current DESCRIPTION "All accessible objects in the AgentX MIB." ::= { agentxMIBGroups 1 } END AgentX Working Group Expires September 1998 [Page 15] Internet Draft AgentX MIB 23 March 1998 5. Acknowledgments This document is a product of the IETF's AgentX Working Group. Special acknowledgement is made to: Maria Greene | Xedia | 119 Russell Street, Littleton MA 01460 | USA | Phone: +1 978-952-6000 | EMail: maria@xedia.com | This MIB is an evolution of the Subagent MIB by Bert Wijnen (wijnen@vnet.ibm.com) which in turn was derived from the SMUX-MIB by Marshall Rose [6]. 6. References [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC1902, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991. [3] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC1905, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [5] Daniele, M., Wijnen, B., and D. Francisco, "Agent Extensibility (AgentX) Protocol, Version 1", draft-ietf-agentx-ext-pro-02.txt, Digital Equipment Corporation, T.J. Watson Research Center, IBM Corp., Cisco Systems, November, 1996. AgentX Working Group Expires September 1998 [Page 16] Internet Draft AgentX MIB 23 March 1998 [6] Rose, M., "SNMP MUX Protocol and MIB", RFC1227, Performance Systems International, Inc., May 1991. [7] Wijnen, B., Carpenter, G., Curran, K., Sehgal, A., and G. Waters, "Simple Network Management Protocol: Distributed Protocol Interface, Version 2.0", RFC 1592, T.J. Watson Research Center, IBM Corp., Bell Northern Research, Ltd., March 1994. [8] F. Yergeau, "UTF-8, a transformation format of Unicode and ISO 10646,", RFC 2044, October 1996. 7. Security Considerations In most cases, MIBs are not themselves security risks; if SNMP security is operating as intended, the use of a MIB to view information about a system, or to change some parameter at the system, is a tool, not a threat. None of the read-only objects in this MIB reports a password, user data, or anything else that is particularly sensitive. If access to these objects is not limited by an appropriate access control policy, these objects can provide an attacker with information about a system's configuration and the services that that system is providing. Some enterprises view their network and system configurations themselves, as well as information about usage and performance, as corporate assets; such enterprises may wish to restrict SNMP access to most of the objects in the MIB. This MIB contains two read-write objects: agentxDefaultTimeout and agentxSessionAdminStatus. Setting agentxDefaultTimeout to an inappropriately small value can prevent new subagent sessions from being usable. Setting agentxSessionAdminStatus to an inappropriate value can effectively prevent access to management information, or provide access to inappropriate information. Since changes to either of these objects can adversely impact the manageability of a system, write access to these objects should be subject to an appropriate access control policy. Such a policy may be realized in an implementation by limiting support for these objects to read-only access. 8. Editor's Address Smitha Gudur BMC Software, Inc. 965 Stewart Drive | Sunnyvale, CA 94086 | USA Phone: +1 408-616-3100 | EMail: sgudur@bmc.com AgentX Working Group Expires September 1998 [Page 17] Internet Draft AgentX MIB 23 March 1998 9. Full Copyright Statement Copyright (C) The Internet Society (1997). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. AgentX Working Group Expires September 1998 [Page 18] --====================987654321_0==_ Content-Type: text/plain; charset="us-ascii" --====================987654321_0==_-- From mdevlin@eltrax.com Mon Mar 23 18:26:45 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id SAA09352 for ; Mon, 23 Mar 1998 18:26:45 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id SAA12008 for ; Mon, 23 Mar 1998 18:26:39 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma011831; Mon, 23 Mar 98 18:25:41 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id SAA26399 for ; Mon, 23 Mar 1998 18:25:22 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma026028; Mon, 23 Mar 98 18:24:42 -0600 Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id QAA06631 for ; Mon, 23 Mar 1998 16:19:48 -0800 (PST) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id SAA23670 for ; Mon, 23 Mar 1998 18:19:46 -0600 (CST) Received: from mail.htconn.com(38.245.21.2) by cashew.bmc.com via smap (V2.0) id xma023637; Mon, 23 Mar 98 18:19:13 -0600 Received: from tmax by mail.htconn.com (SMI-8.6/SMI-SVR4) id TAA19105; Mon, 23 Mar 1998 19:14:04 -0500 From: mdevlin@eltrax.com (T. Max Devlin) To: agentx@peer.com Subject: Re: draft-ietf-agentx-mib-02.txt Date: Tue, 24 Mar 1998 00:01:11 GMT Organization: Eltrax Systems/Hi-TECH Connections Message-ID: <3522f5ad.21793007@mail.htconn.com> References: <19980323233125.3626.qmail@hotmail.com> In-Reply-To: <19980323233125.3626.qmail@hotmail.com> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thank you, Smitha, for the document. Smitha Gudur said: >To: agentx@peer.com >Subject: draft-ietf-agentx-mib-02.txt >From: "Smitha Gudur" >Date: Mon, 23 Mar 1998 15:31:24 PST > > > >______________________________________________________ >Get Your Private, Free Email at http://www.hotmail.com > > Is anyone else bothered by this included bit of advertisement? I know, I know, "It's free email, what do you want?" But it doesn't seem all that free. I mean, billboard owners and TV broadcasters get paid for displaying someone else's advertising. Seems using this service is costing Smitha Gudur something after all. Sorry, I'll stop proselytizing. Forgive my outburst. But seems there oughta be a line somewhere. I mean, they didn't even put a sig delimiter above it; it would be included in a quoting message by default. -- T. Max Devlin Hi-TECH Connections/Eltrax Systems ***************************************************** - Opinions expressed are my own. Anyone else may use them only in accordance with licensing agreements. - From gisli@research.att.com Mon Mar 23 18:47:26 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id SAA09622 for ; Mon, 23 Mar 1998 18:47:26 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id SAA14192 for ; Mon, 23 Mar 1998 18:47:20 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma013978; Mon, 23 Mar 98 18:46:49 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id SAA06320 for ; Mon, 23 Mar 1998 18:46:27 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma005909; Mon, 23 Mar 98 18:46:11 -0600 Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id QAA06803 for ; Mon, 23 Mar 1998 16:39:44 -0800 (PST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id SAA12467 for ; Mon, 23 Mar 1998 18:39:43 -0600 (CST) Received: from rumor.research.att.com(192.20.225.9) by almond.bmc.com via smap (V2.0) id xma012447; Mon, 23 Mar 98 18:39:19 -0600 Received: from research.att.com ([135.207.30.100]) by rumor; Mon Mar 23 19:35:49 EST 1998 Received: from alliance.research.att.com ([135.207.26.26]) by research-clone; Mon Mar 23 19:39:04 EST 1998 Received: from eyland.research.att.com ([135.207.14.180]) by alliance.research.att.com (8.8.7/8.8.7) with SMTP id TAA27348 for ; Mon, 23 Mar 1998 19:39:14 -0500 (EST) Reply-To: "Gisli Hjalmtysson" From: "Gisli Hjalmtysson" To: Subject: unsubscribe Date: Mon, 23 Mar 1998 19:38:39 -0500 Message-ID: <01bd56bd$3029dee0$b40ecf87@eyland.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 unsubscribe From dbh@ctron.com Mon Mar 23 18:50:00 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id SAA09659 for ; Mon, 23 Mar 1998 18:50:00 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id SAA15026 for ; Mon, 23 Mar 1998 18:49:55 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma014211; Mon, 23 Mar 98 18:47:22 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id SAA06593 for ; Mon, 23 Mar 1998 18:47:00 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma006307; Mon, 23 Mar 98 18:46:27 -0600 Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id QAA06818 for ; Mon, 23 Mar 1998 16:41:14 -0800 (PST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id SAA12511 for ; Mon, 23 Mar 1998 18:41:13 -0600 (CST) Received: from ctron-mail.cabletron.com(134.141.197.33) by almond.bmc.com via smap (V2.0) id xma012507; Mon, 23 Mar 98 18:41:06 -0600 Received: from roc-mail2.ctron.com (roc-mail2 [134.141.72.230]) by ctron-mail.ctron.com (8.8.7/8.8.7) with ESMTP id TAA07605; Mon, 23 Mar 1998 19:41:04 -0500 (EST) Received: from dur-mail.ctron.com (dur-mail [134.141.69.20]) by roc-mail2.ctron.com (8.8.7/8.8.7) with ESMTP id TAA27489; Mon, 23 Mar 1998 19:40:27 -0500 (EST) Received: from gimli (gimli.ctron.com [134.141.64.24]) by dur-mail.ctron.com (8.8.7/8.8.7) with SMTP id TAA05130; Mon, 23 Mar 1998 19:49:56 -0500 (EST) Sender: dbh@cabletron.com Message-ID: <351700D5.4BEB@ctron.com> Date: Mon, 23 Mar 1998 19:39:49 -0500 From: David Harrington Organization: Cabletron Systems, Inc. X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: "T. Max Devlin" CC: agentx@peer.com Subject: Re: draft-ietf-agentx-mib-02.txt References: <19980323233125.3626.qmail@hotmail.com> <3522f5ad.21793007@mail.htconn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit T. Max Devlin wrote: > > Thank you, Smitha, for the document. > > Smitha Gudur said: > >To: agentx@peer.com > >Subject: draft-ietf-agentx-mib-02.txt > >From: "Smitha Gudur" > >Date: Mon, 23 Mar 1998 15:31:24 PST > > > > > > > >______________________________________________________ > >Get Your Private, Free Email at http://www.hotmail.com > > > > > Is anyone else bothered by this included bit of advertisement? I know, I also thought it seemed out of place. I appreciate that it is very subdued, but it is still advertising being sent to a mailing list, and I felt it stepped over the line just so slightly. -- ----------------------------------------------------- #include David Harrington dbh@ctron.com Spectrum Network Management Platform Core Group Cabletron Systems Inc. ----------------------------------------------------- From mwhite@cmu.edu Tue Mar 24 00:32:30 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id AAA13977 for ; Tue, 24 Mar 1998 00:32:30 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id AAA26449 for ; Tue, 24 Mar 1998 00:32:23 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma026128; Tue, 24 Mar 98 00:31:35 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id AAA09676 for ; Tue, 24 Mar 1998 00:31:15 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma009547; Tue, 24 Mar 98 00:31:02 -0600 Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id WAA10993 for ; Mon, 23 Mar 1998 22:26:06 -0800 (PST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id AAA25229 for ; Tue, 24 Mar 1998 00:26:04 -0600 (CST) Received: from cmu1.acs.cmu.edu(128.2.35.186) by almond.bmc.com via smap (V2.0) id xma025220; Tue, 24 Mar 98 00:25:51 -0600 Received: from BITES.ADSL.NET.CMU.EDU (BITES.ADSL.NET.CMU.EDU [128.2.108.201]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id BAA16932 for ; Tue, 24 Mar 1998 01:25:47 -0500 (EST) Date: Tue, 24 Mar 1998 01:25:47 -0500 From: "Matt White" To: agentx@peer.com Subject: Re: draft-ietf-agentx-mib-02.txt Message-ID: <1644517618.890702747@BITES.ADSL.NET.CMU.EDU> X-Mailer: Mulberry (Win32) [1.3.1, s/n S-100002] X-Authenticated: mwhite by cyrus.andrew.cmu.edu X-Licensed-To: Campus User MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I believe the hotmail mail servers adds that tag to the end of all outgoing messages. Unless someone wants to provide Smitha with a free email account, perhaps we should not be so critical. -Matt --On Monday, March 23, 1998, 7:39 PM -0500 "David Harrington" wrote: > T. Max Devlin wrote: >> >> Thank you, Smitha, for the document. >> >> Smitha Gudur said: >> >To: agentx@peer.com >> >Subject: draft-ietf-agentx-mib-02.txt >> >From: "Smitha Gudur" >> >Date: Mon, 23 Mar 1998 15:31:24 PST >> > >> > >> > >> >______________________________________________________ >> >Get Your Private, Free Email at http://www.hotmail.com >> > >> > >> Is anyone else bothered by this included bit of advertisement? I know, > > I also thought it seemed out of place. > I appreciate that it is very subdued, but it is still advertising > being sent to a mailing list, and I felt it stepped over the line > just so slightly. > > -- > ----------------------------------------------------- > #include > David Harrington dbh@ctron.com > Spectrum Network Management Platform Core Group > Cabletron Systems Inc. > ----------------------------------------------------- From aecl@pelsys.com Tue Mar 24 09:05:43 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id JAA19624 for ; Tue, 24 Mar 1998 09:05:43 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id JAA16053 for ; Tue, 24 Mar 1998 09:05:36 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma015833; Tue, 24 Mar 98 09:04:58 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id JAA23930 for ; Tue, 24 Mar 1998 09:04:37 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma023563; Tue, 24 Mar 98 09:04:14 -0600 Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA20900 for ; Tue, 24 Mar 1998 06:57:31 -0800 (PST) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id IAA23168 for ; Tue, 24 Mar 1998 08:57:24 -0600 (CST) Received: from gauntlet.fv.com(207.67.199.118) by cashew.bmc.com via smap (V2.0) id xma023154; Tue, 24 Mar 98 08:57:04 -0600 Received: (from uucp@localhost) by gauntlet.fv.com (8.8.8/8.8.8) id GAA15889 for ; Tue, 24 Mar 1998 06:58:58 -0800 (PST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (4.0a) id xma015881; Tue, 24 Mar 98 06:58:05 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.8/8.8.8) with ESMTP id GAA06784 for ; Tue, 24 Mar 1998 06:55:59 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.8/8.8.8) id GAA15876 for ; Tue, 24 Mar 1998 06:57:59 -0800 (PST) Received: from shiva.jussieu.fr(134.157.0.129) by gauntlet.fv.com via smap (4.0a) id xma015872; Tue, 24 Mar 98 06:57:53 -0800 Received: from unix.artemis.jussieu.fr (root@unix.artemis.jussieu.fr [134.157.55.10]) by shiva.jussieu.fr (8.8.8/jtpda-5.3) with ESMTP id PAA15293 ; Tue, 24 Mar 1998 15:53:55 +0100 (CET) Received: from pelsys.com (dione.artemis.jussieu.fr [134.157.55.57]) by unix.artemis.jussieu.fr (8.8.7/jtpda-5.2) with ESMTP id PAA03492 ; Tue, 24 Mar 1998 15:45:20 GMT Message-ID: <3517C8A0.42C40750@pelsys.com> Date: Tue, 24 Mar 1998 15:52:17 +0100 From: aecl X-Mailer: Mozilla 4.03 [fr] (Win95; I) MIME-Version: 1.0 To: agentx@fv.com, hostmib@andrew.cmu.edu, rdbms@us.oracle.com, rmonmib@cisco.com, applmib@emi-summit.com Subject: (pas d'objet) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit subscribe From bnatale@acecomm.com Tue Mar 24 10:00:19 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id KAA20230 for ; Tue, 24 Mar 1998 10:00:18 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA21436 for ; Tue, 24 Mar 1998 10:00:11 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma021147; Tue, 24 Mar 98 09:59:20 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id JAA21521 for ; Tue, 24 Mar 1998 09:58:59 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma020910; Tue, 24 Mar 98 09:58:33 -0600 Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA21019 for ; Tue, 24 Mar 1998 07:53:30 -0800 (PST) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id JAA26755 for ; Tue, 24 Mar 1998 09:53:29 -0600 (CST) Received: from relay1.smtp.psi.net(38.8.14.2) by cashew.bmc.com via smap (V2.0) id xma026742; Tue, 24 Mar 98 09:53:01 -0600 Received: from nips.acec.com by relay1.smtp.psi.net (8.8.5/SMI-5.4-PSI) id KAA29849; Tue, 24 Mar 1998 10:52:51 -0500 (EST) Received: from bnatale by nips.acec.com (5.65/3.2.083191-ACE*COMM) id AA29087; Tue, 24 Mar 1998 10:52:57 -0500 Message-Id: <3.0.5.32.19980324105635.0096d220@nips.acec.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 24 Mar 1998 10:56:35 -0500 To: "Matt White" From: Bob Natale Subject: Re: hotmail.com Cc: agentx@peer.com In-Reply-To: <1644517618.890702747@BITES.ADSL.NET.CMU.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 01:25 AM 3/24/98 -0500, Matt White wrote: Hi Matt, This thread is definitely on the noise side of the equation, so I have both changed the Subject: header to let people more easily DEL any follow-ups and am hoping that I will hereby have the last word on the matter. :-) >I believe the hotmail mail servers adds that tag to the end >of all outgoing messages. Unless someone wants to provide >Smitha with a free email account, perhaps we should not be >so critical. Very true. In fact, my own .sig (and those of many other posters) is far more "intrusive". Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ---- WinSNMP DLL, SDK, Apps & Agents for Win16/32 & UNIX ---- ------ NetPlus (r) "FCAPS" Telemanagement Applications ------ From schoenw@ibr.cs.tu-bs.de Tue Mar 24 11:59:31 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id LAA21837 for ; Tue, 24 Mar 1998 11:59:31 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA00964 for ; Tue, 24 Mar 1998 11:59:23 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma000701; Tue, 24 Mar 98 11:58:16 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA11625 for ; Tue, 24 Mar 1998 11:57:57 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma011340; Tue, 24 Mar 98 11:57:44 -0600 Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA21571 for ; Tue, 24 Mar 1998 09:52:16 -0800 (PST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA29458 for ; Tue, 24 Mar 1998 11:52:15 -0600 (CST) Received: from ra.ibr.cs.tu-bs.de(134.169.34.12) by almond.bmc.com via smap (V2.0) id xma029433; Tue, 24 Mar 98 11:51:52 -0600 Received: from henkell.ibr.cs.tu-bs.de (henkell [134.169.34.191]) by ra.ibr.cs.tu-bs.de (8.8.6/8.8.6) with ESMTP id SAA17598 for ; Tue, 24 Mar 1998 18:51:46 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id SAA07586; Tue, 24 Mar 1998 18:51:45 +0100 Date: Tue, 24 Mar 1998 18:51:45 +0100 Message-Id: <199803241751.SAA07586@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: agentx@peer.com In-reply-to: <19980323233125.3626.qmail@hotmail.com> (sgudur@hotmail.com) Subject: Re: draft-ietf-agentx-mib-02.txt References: <19980323233125.3626.qmail@hotmail.com> >>>>> Smitha Gudur writes: Smitha> This is a posting of revised AgentX MIB. The revisions are Smitha> made based on the inputs received from mailing list. This has Smitha> been changed accordingly. I have done a quick review of the new MIB and I have some comments: - Please change AgentxSubagentEntry to AgentxSessionEntry. (This is just to follow common practice and to keep MIB parsers happy.) - agentxMasterTransports and agentxConnTransportType define unixDomainSockets, tcp, udp, sharedMem and other. RFC 2257 only defines Unix Domain Sockets and TCP as transports. What is the rationale for including UDP and shared memory? - agentxConnTransportAddr is of type OCTET STRING and supposed to hold the transport address, in network byte order. It is unclear to me what this exactly means for all the transports listed above. I am also not really happy that we use yet another transport address type instead of TDomain and TAddress. (I know, we don't have definitions for a TCP domain or UNIX domain sockets, but this is something which has to be defined anyway.) - agentxRegContext is defined as OCTET STRING (without any size constraints). How does that related to SNMPv3 contexts, which show up in e.g. VACM as SnmpAdminString (SIZE (0..32))? Or do we talk here about SNMPv1/SNMPv2c community strings? - agentxSessionAgentXVer is of type INTEGER (1..256). There is one byte in the AgentX protocol reserved for the AgentX version. So I guess the correct range is (0..255). (Will version 0 every be used by AgentX?) - Is the new MIB going to be posted as an ID? It would be easier to find the recent version if it can be found in the usual places and if it is listed on the AgentX charter page of the IETF. Thats it for now, Juergen -- Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3283) From bnatale@acecomm.com Tue Mar 24 13:11:35 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA22809 for ; Tue, 24 Mar 1998 13:11:30 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA05513 for ; Tue, 24 Mar 1998 13:11:24 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma005288; Tue, 24 Mar 98 13:10:46 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA16860 for ; Tue, 24 Mar 1998 13:10:26 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma016518; Tue, 24 Mar 98 13:10:10 -0600 Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA23404 for ; Tue, 24 Mar 1998 11:03:39 -0800 (PST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA04036 for ; Tue, 24 Mar 1998 13:03:38 -0600 (CST) Received: from relay1.smtp.psi.net(38.8.14.2) by almond.bmc.com via smap (V2.0) id xma004028; Tue, 24 Mar 98 13:03:35 -0600 Received: from nips.acec.com by relay1.smtp.psi.net (8.8.5/SMI-5.4-PSI) id OAA20777; Tue, 24 Mar 1998 14:03:16 -0500 (EST) Received: from bnatale by nips.acec.com (5.65/3.2.083191-ACE*COMM) id AA02873; Tue, 24 Mar 1998 14:03:08 -0500 Message-Id: <3.0.5.32.19980324140646.0095f7b0@nips.acec.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 24 Mar 1998 14:06:46 -0500 To: Juergen Schoenwaelder From: Bob Natale Subject: Re: draft-ietf-agentx-mib-02.txt Cc: agentx@peer.com In-Reply-To: <199803241751.SAA07586@henkell.ibr.cs.tu-bs.de> References: <19980323233125.3626.qmail@hotmail.com> <19980323233125.3626.qmail@hotmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 06:51 PM 3/24/98 +0100, Juergen Schoenwaelder wrote: Hi Juergen, <...> >- Is the new MIB going to be posted as an ID? It would be > easier to find the recent version if it can be found in > the usual places and if it is listed on the AgentX charter > page of the IETF. Yes. Since there was something of a hiatus between the main discussion of the last posted version of the MIB and this edition, we thought it might be best to give the list a quick shot at it first...and we thought that since AgentX is not meeting at the L.A. IETF, we would not further occupy the Secretariat's resources until afterwards. Ok? > Thats it for now, Thanks for the input. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ---- WinSNMP DLL, SDK, Apps & Agents for Win16/32 & UNIX ---- ------ NetPlus (r) "FCAPS" Telemanagement Applications ------ From mdevlin@eltrax.com Tue Mar 24 16:39:49 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id QAA25570 for ; Tue, 24 Mar 1998 16:39:49 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA18653 for ; Tue, 24 Mar 1998 16:39:42 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma018458; Tue, 24 Mar 98 16:38:49 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA21114 for ; Tue, 24 Mar 1998 16:38:30 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma020476; Tue, 24 Mar 98 16:37:58 -0600 Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA02219 for ; Tue, 24 Mar 1998 14:32:51 -0800 (PST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA17165 for ; Tue, 24 Mar 1998 16:32:50 -0600 (CST) Received: from mail.htconn.com(38.245.21.2) by almond.bmc.com via smap (V2.0) id xma017163; Tue, 24 Mar 98 16:32:38 -0600 Received: from tmax by mail.htconn.com (SMI-8.6/SMI-SVR4) id RAA19606; Tue, 24 Mar 1998 17:27:31 -0500 From: mdevlin@eltrax.com (T. Max Devlin) To: agentx@peer.com Subject: Re: hotmail.com Date: Tue, 24 Mar 1998 22:14:31 GMT Organization: Eltrax Systems/Hi-TECH Connections Message-ID: <351d3028.2928388@mail.htconn.com> References: <3.0.5.32.19980324105635.0096d220@nips.acec.com> In-Reply-To: <3.0.5.32.19980324105635.0096d220@nips.acec.com> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob Natale said: >>At 01:25 AM 3/24/98 -0500, Matt White wrote: > >Hi Matt, > >This thread is definitely on the noise side of the equation, >so I have both changed the Subject: header to let people more >easily DEL any follow-ups and am hoping that I will hereby >have the last word on the matter. :-) As originator of this line of whining, I think I'll see you a subject change, and raise you a follow-up. > >>I believe the hotmail mail servers adds that tag to the end >>of all outgoing messages. Unless someone wants to provide >>Smitha with a free email account, perhaps we should not be >>so critical. > >Very true. In fact, my own .sig (and those of many other >posters) is far more "intrusive". > >Cordially, > >BobN >------------ ISO 9001 Registered Quality Supplier ----------- >Bob Natale | ACE*COMM | 301-721-3000 [v] >Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] >bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com >---- WinSNMP DLL, SDK, Apps & Agents for Win16/32 & UNIX ---- >------ NetPlus (r) "FCAPS" Telemanagement Applications ------ > Well, you found me out. I guess I have to admit that had you been bought by one of the richest and most powerful corporations in the world immediately before you started using your .sig, I probably would have mentioned how annoying it is. ;-) -- T. Max Devlin Hi-TECH Connections/Eltrax Systems ***************************************************** - Opinions expressed are my own. Anyone else may use them only in accordance with licensing agreements. - From sgudur@hotmail.com Tue Mar 24 18:08:38 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id SAA26773 for ; Tue, 24 Mar 1998 18:08:38 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id SAA23914 for ; Tue, 24 Mar 1998 18:08:30 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma023689; Tue, 24 Mar 98 18:07:38 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id SAA20149 for ; Tue, 24 Mar 1998 18:07:18 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma019989; Tue, 24 Mar 98 18:07:08 -0600 Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id PAA05403 for ; Tue, 24 Mar 1998 15:59:11 -0800 (PST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA22458 for ; Tue, 24 Mar 1998 17:59:09 -0600 (CST) Received: from f77.hotmail.com(207.82.250.183) by almond.bmc.com via smap (V2.0) id xma022450; Tue, 24 Mar 98 17:58:59 -0600 Received: (qmail 1760 invoked by uid 0); 24 Mar 1998 23:58:57 -0000 Message-ID: <19980324235857.1759.qmail@hotmail.com> Received: from 152.67.249.57 by www.hotmail.com with HTTP; Tue, 24 Mar 1998 15:58:56 PST X-Originating-IP: [152.67.249.57] From: "Smitha Gudur" To: schoenw@ibr.cs.tu-bs.de Cc: agentx@peer.com Subject: Re: draft-ietf-agentx-mib-02.txt Content-Type: text/plain Date: Tue, 24 Mar 1998 15:58:56 PST >From schoenw@ibr.cs.tu-bs.de Tue Mar 24 09:55:18 1998 >Received: (from uucp@localhost) > by almond.bmc.com (8.8.8/8.8.8) id LAA29754; > Tue, 24 Mar 1998 11:55:14 -0600 (CST) >Received: from firewall.bmc.com(192.245.162.250) > by almond.bmc.com via smap (V2.0) > id xma029696; Tue, 24 Mar 98 11:54:52 -0600 >Received: (from uucp@localhost) > by dresden.bmc.com (8.8.5/8.8.6) id LAA08325; > Tue, 24 Mar 1998 11:54:32 -0600 (CST) >Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) > id xma007959; Tue, 24 Mar 98 11:54:00 -0600 >Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) > by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA21571 > for ; Tue, 24 Mar 1998 09:52:16 -0800 (PST) >Received: (from uucp@localhost) > by almond.bmc.com (8.8.8/8.8.8) id LAA29458 > for ; Tue, 24 Mar 1998 11:52:15 -0600 (CST) >Received: from ra.ibr.cs.tu-bs.de(134.169.34.12) > by almond.bmc.com via smap (V2.0) > id xma029433; Tue, 24 Mar 98 11:51:52 -0600 >Received: from henkell.ibr.cs.tu-bs.de (henkell [134.169.34.191]) > by ra.ibr.cs.tu-bs.de (8.8.6/8.8.6) with ESMTP id SAA17598 > for ; Tue, 24 Mar 1998 18:51:46 +0100 (MET) >Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id SAA07586; Tue, 24 Mar 1998 18:51:45 +0100 >Date: Tue, 24 Mar 1998 18:51:45 +0100 >Message-Id: <199803241751.SAA07586@henkell.ibr.cs.tu-bs.de> >From: Juergen Schoenwaelder >To: agentx@peer.com >In-reply-to: <19980323233125.3626.qmail@hotmail.com> (sgudur@hotmail.com) >Subject: Re: draft-ietf-agentx-mib-02.txt >References: <19980323233125.3626.qmail@hotmail.com> > >I have done a quick review of the new MIB and I have some comments: > >- Please change AgentxSubagentEntry to AgentxSessionEntry. (This is > just to follow common practice and to keep MIB parsers happy.) Yes. This needs to be changed. > >- agentxMasterTransports and agentxConnTransportType define > unixDomainSockets, tcp, udp, sharedMem and other. RFC 2257 only > defines Unix Domain Sockets and TCP as transports. What is the > rationale for including UDP and shared memory? RFC 2257 states taht TCP or any local mechanism suchas shared memory, named pipe can be used. This is stated in section 9. > >- agentxRegContext is defined as OCTET STRING (without any size > constraints). How does that related to SNMPv3 contexts, which show > up in e.g. VACM as SnmpAdminString (SIZE (0..32))? Or do we talk > here about SNMPv1/SNMPv2c community strings? > For SNMPv1/SNMPv2 community string can be used as an index to community profiles or more complext content information. so this cannot be restricted as it is implementation specific. This is specified in section 6.1.1 of RFC 2257. >- agentxSessionAgentXVer is of type INTEGER (1..256). There is one > byte in the AgentX protocol reserved for the AgentX version. So I > guess the correct range is (0..255). (Will version 0 every be used > by AgentX?) As RFC 2257 states that version = 1. It will not be going backwards to zero. > >- Is the new MIB going to be posted as an ID? It would be easier to > find the recent version if it can be found in the usual places and > if it is listed on the AgentX charter page of the IETF. > >Thats it for now, > Juergen >-- >Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw >Technical University Braunschweig, Dept. Operating Systems & Computer Networks >Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3283) > smitha ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From schoenw@ibr.cs.tu-bs.de Thu Mar 26 09:38:13 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id JAA29017 for ; Thu, 26 Mar 1998 09:38:13 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id JAA05213 for ; Thu, 26 Mar 1998 09:38:02 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma004827; Thu, 26 Mar 98 09:36:34 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id JAA03832 for ; Thu, 26 Mar 1998 09:36:12 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma003518; Thu, 26 Mar 98 09:35:55 -0600 Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA03902 for ; Thu, 26 Mar 1998 07:26:17 -0800 (PST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id JAA03402 for ; Thu, 26 Mar 1998 09:26:16 -0600 (CST) Received: from ra.ibr.cs.tu-bs.de(134.169.34.12) by almond.bmc.com via smap (V2.0) id xma003387; Thu, 26 Mar 98 09:26:13 -0600 Received: from henkell.ibr.cs.tu-bs.de (henkell [134.169.34.191]) by ra.ibr.cs.tu-bs.de (8.8.6/8.8.6) with ESMTP id QAA20690; Thu, 26 Mar 1998 16:26:02 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id QAA14979; Thu, 26 Mar 1998 16:26:01 +0100 Date: Thu, 26 Mar 1998 16:26:01 +0100 Message-Id: <199803261526.QAA14979@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: sgudur@hotmail.com CC: agentx@peer.com In-reply-to: <19980324235857.1759.qmail@hotmail.com> (sgudur@hotmail.com) Subject: Re: draft-ietf-agentx-mib-02.txt References: <19980324235857.1759.qmail@hotmail.com> >>>>> Smitha Gudur writes: >> - agentxMasterTransports and agentxConnTransportType define >> unixDomainSockets, tcp, udp, sharedMem and other. RFC 2257 only >> defines Unix Domain Sockets and TCP as transports. What is the >> rationale for including UDP and shared memory? Smitha> RFC 2257 states taht TCP or any local mechanism suchas shared Smitha> memory, named pipe can be used. This is stated in section 9. RFC 2257 defines TCP and Unix Domain Sockets as a transport. RFC 2257 mentions shared memory and named pipes in the security section. The AgentX MIB draft lists unixDomainSockets, tcp, udp, sharedMem and other. This does not match very well. I see three possible solutions: 1) The MIB only enumerates the officially defined AgentX transports and other. 2) The MIB lists all possible known AgentX transports plus other. This means that we have to define the format of agentxConnTransportAddr as well for each transport. 3) agentxConnTransportType and agentxConnTransportAddr are changed to agentxConnTransportDomain (TDomain) and agentxConnTransportAddr (TAddress). I think option 3) is the way to go. >> - agentxRegContext is defined as OCTET STRING (without any size >> constraints). How does that related to SNMPv3 contexts, which show >> up in e.g. VACM as SnmpAdminString (SIZE (0..32))? Or do we talk >> here about SNMPv1/SNMPv2c community strings? Smitha> For SNMPv1/SNMPv2 community string can be used as an index to Smitha> community profiles or more complext content information. so Smitha> this cannot be restricted as it is implementation specific. Smitha> This is specified in section 6.1.1 of RFC 2257. We should probably add text which clarifies that this is indeed the community string for SNMPv1/SNMPv2 agents. The reason why I would like to see more clarity here is that the SNMPv3 community MIB proposed on the SNMPv3 list provides a mapping of an SNMPv1/SNMPv2 community string to an SNMPv3 contextName, which is obviously not supposed to go into this attribute. However, I would expect the contextName to go here for an SNMPv3 master agent, right? >> - agentxSessionAgentXVer is of type INTEGER (1..256). There is one >> byte in the AgentX protocol reserved for the AgentX version. So I >> guess the correct range is (0..255). (Will version 0 every be used >> by AgentX?) Smitha> As RFC 2257 states that version = 1. It will not be going Smitha> backwards to zero. If that is true, the range should be (1..255). Juergen -- Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3283) From bnatale@acecomm.com Thu Mar 26 10:39:03 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id KAA29832 for ; Thu, 26 Mar 1998 10:39:03 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA10604 for ; Thu, 26 Mar 1998 10:38:52 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma010111; Thu, 26 Mar 98 10:36:15 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id KAA28021 for ; Thu, 26 Mar 1998 10:35:56 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma027614; Thu, 26 Mar 98 10:35:35 -0600 Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA04027 for ; Thu, 26 Mar 1998 08:29:13 -0800 (PST) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id KAA13668 for ; Thu, 26 Mar 1998 10:28:56 -0600 (CST) Received: from relay1.smtp.psi.net(38.8.14.2) by cashew.bmc.com via smap (V2.0) id xma013663; Thu, 26 Mar 98 10:28:49 -0600 Received: from nips.acec.com by relay1.smtp.psi.net (8.8.5/SMI-5.4-PSI) id LAA01973; Thu, 26 Mar 1998 11:28:36 -0500 (EST) Received: from bnatale by nips.acec.com (5.65/3.2.083191-ACE*COMM) id AA02543; Thu, 26 Mar 1998 11:28:25 -0500 Message-Id: <3.0.5.32.19980326113205.00953d20@nips.acec.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 26 Mar 1998 11:32:05 -0500 To: Juergen Schoenwaelder From: Bob Natale Subject: Re: draft-ietf-agentx-mib-02.txt Cc: sgudur@hotmail.com, agentx@peer.com In-Reply-To: <199803261526.QAA14979@henkell.ibr.cs.tu-bs.de> References: <19980324235857.1759.qmail@hotmail.com> <19980324235857.1759.qmail@hotmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 04:26 PM 3/26/98 +0100, Juergen Schoenwaelder wrote: Hi Juergen, <...> >RFC 2257 defines TCP and Unix Domain Sockets as a transport. RFC 2257 >mentions shared memory and named pipes in the security section. The >AgentX MIB draft lists unixDomainSockets, tcp, udp, sharedMem and >other. This does not match very well. I see three possible solutions: > >1) The MIB only enumerates the officially defined AgentX transports > and other. >2) The MIB lists all possible known AgentX transports plus other. This > means that we have to define the format of agentxConnTransportAddr > as well for each transport. >3) agentxConnTransportType and agentxConnTransportAddr are changed > to agentxConnTransportDomain (TDomain) and agentxConnTransportAddr > (TAddress). > >I think option 3) is the way to go. I agree. <...> >We should probably add text which clarifies that this is indeed the >community string for SNMPv1/SNMPv2 agents. The reason why I would like >to see more clarity here is that the SNMPv3 community MIB proposed on >the SNMPv3 list provides a mapping of an SNMPv1/SNMPv2 community >string to an SNMPv3 contextName, which is obviously not supposed to go >into this attribute. However, I would expect the contextName to go >here for an SNMPv3 master agent, right? Yes, that is my understanding. <...> >Smitha> As RFC 2257 states that version = 1. It will not be going >Smitha> backwards to zero. > >If that is true, the range should be (1..255). Correct. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ---- WinSNMP DLL, SDK, Apps & Agents for Win16/32 & UNIX ---- ------ NetPlus (r) "FCAPS" Telemanagement Applications ------ From rpresuhn@dorothy.peer.com Thu Mar 26 12:26:00 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id MAA01277 for ; Thu, 26 Mar 1998 12:26:00 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA18014 for ; Thu, 26 Mar 1998 12:25:49 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma017581; Thu, 26 Mar 98 12:23:12 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA26067 for ; Thu, 26 Mar 1998 12:22:53 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma025779; Thu, 26 Mar 98 12:22:36 -0600 Received: (from rpresuhn@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id KAA05339 for agentx@peer.com; Thu, 26 Mar 1998 10:16:52 -0800 (PST) Date: Thu, 26 Mar 1998 10:16:52 -0800 (PST) From: Randy Presuhn Message-Id: <199803261816.KAA05339@dorothy.peer.com> To: agentx@peer.com Subject: Re: draft-ietf-agentx-mib-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - (Our IS people are "fixing" our email systems again, so I'm a bit late in getting into this thread. I'm picking it up from the archive.) > Date: Thu, 26 Mar 1998 16:26:01 +0100 > From: Juergen Schoenwaelder > To: sgudur@hotmail.com > CC: agentx@peer.com > Subject: Re: draft-ietf-agentx-mib-02.txt > References: <19980324235857.1759.qmail@hotmail.com> ... > >> - agentxRegContext is defined as OCTET STRING (without any size > >> constraints). How does that related to SNMPv3 contexts, which show > >> up in e.g. VACM as SnmpAdminString (SIZE (0..32))? Or do we talk > >> here about SNMPv1/SNMPv2c community strings? I think it should be constrained down to SnmpAdminString. This was discussed on this list around October 30, 1997. > Smitha> For SNMPv1/SNMPv2 community string can be used as an index to > Smitha> community profiles or more complext content information. so > Smitha> this cannot be restricted as it is implementation specific. > Smitha> This is specified in section 6.1.1 of RFC 2257. See Bob Natale's comments on this topic, also October 30, 1997. > We should probably add text which clarifies that this is indeed the > community string for SNMPv1/SNMPv2 agents. The reason why I would like > to see more clarity here is that the SNMPv3 community MIB proposed on > the SNMPv3 list provides a mapping of an SNMPv1/SNMPv2 community > string to an SNMPv3 contextName, which is obviously not supposed to go > into this attribute. ... I disagree. The most useful / meaningful information to put into this field is indeed the contextName. Community strings can have a many-to- one mapping to contextNames. Community strings can be overloaded with authentication, as well as naming semantics. The purpose of agentxRegContext is to identify which "naming scope" information belongs to. contextName fits this decription, community strings do not. ... > However, I would expect the contextName to go > here for an SNMPv3 master agent, right? ... I agree, but not just for SNMPv3 agents. A particular implementation or configuration MIGHT have a one-to-one or identity mapping between community strings and contextNames, but it would be a big mistake to require it, especially in multi-lingual master agents. The attribute should ALWAYS be a contextName. If the master agent happens to be limited to v1 or v2, the mapping would be implementation- specific, but should certainly be aligned with the SNMPv3 contextName semantics. ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From rpresuhn@dorothy.peer.com Fri Mar 27 12:10:41 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id MAA20587 for ; Fri, 27 Mar 1998 12:10:41 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA21178 for ; Fri, 27 Mar 1998 12:10:27 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma021008; Fri, 27 Mar 98 12:09:34 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA13736 for ; Fri, 27 Mar 1998 12:09:14 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma013394; Fri, 27 Mar 98 12:09:01 -0600 Received: (from rpresuhn@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id JAA11601 for agentx@peer.com; Fri, 27 Mar 1998 09:58:00 -0800 (PST) Date: Fri, 27 Mar 1998 09:58:00 -0800 (PST) From: Randy Presuhn Message-Id: <199803271758.JAA11601@dorothy.peer.com> To: agentx@peer.com Subject: fwd: rfc2257 implementation question Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - Query forwarded from agentx-request@peer.com ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@peer.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- > From sripada@ficon-tech.com Fri Mar 27 08:45:04 PST 1998 > Date: Fri, 27 Mar 1998 11:39:52 -0500 > From: Radhakrishna Sripada > Organization: Ficon Technology > To: agentx-request@fv.com > Subject: Subscribe sripada@ficon-tech.com > > Has anyone implemented AGENTX protocol so far as per the RFC2257 ? > > > > From mwhite@cmu.edu Fri Mar 27 13:03:40 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA21295 for ; Fri, 27 Mar 1998 13:03:39 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA24561 for ; Fri, 27 Mar 1998 13:03:25 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma024454; Fri, 27 Mar 98 13:02:54 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA02277 for ; Fri, 27 Mar 1998 13:02:35 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma001980; Fri, 27 Mar 98 13:02:19 -0600 Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA15206 for ; Fri, 27 Mar 1998 10:56:27 -0800 (PST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA23099 for ; Fri, 27 Mar 1998 12:56:24 -0600 (CST) Received: from cmu1.acs.cmu.edu(128.2.35.186) by almond.bmc.com via smap (V2.0) id xma023066; Fri, 27 Mar 98 12:55:55 -0600 Received: from SUBNET86.DYNAMIC.NET.CMU.EDU (SUBNET86.DYNAMIC.NET.CMU.EDU [128.2.86.81]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id NAA26719 for ; Fri, 27 Mar 1998 13:55:53 -0500 (EST) Date: Fri, 27 Mar 1998 13:55:51 -0500 From: "Matt White" To: agentx@peer.com Subject: Re: fwd: rfc2257 implementation question Message-ID: <1948721478.891006951@SUBNET86.DYNAMIC.NET.CMU.EDU> X-Mailer: Mulberry (Win32) [1.3.1, s/n S-100002] X-Authenticated: mwhite by cyrus.andrew.cmu.edu X-Licensed-To: Campus User MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit There aren't any available implementations of RFC 2257 yet as far as I know. I'll be releasing an alpha that implements a subset of AgentX sometime after IETF. It won't be ready for prime time by any means, but it will give people something to play with. -Matt --On Friday, March 27, 1998, 9:58 AM -0800 "Randy Presuhn" wrote: > Hi - > > Query forwarded from agentx-request@peer.com > > ----------------------------------------------------------------------- > Randy Presuhn Email: rpresuhn@peer.com http://www.bmc.com > Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive > Fax: +1 408 616-3101 Sunnyvale, California 94086 USA > ----------------------------------------------------------------------- > In accordance with the BMC Communications Systems Use and Security > Policy, I explicitly state that although my affiliation with BMC may be > apparent, implied, or provided, my opinions are not necessarily those > of BMC Software and that all external representations on behalf of > BMC must first be cleared with a member of "the top management team." > ----------------------------------------------------------------------- > >> From sripada@ficon-tech.com Fri Mar 27 08:45:04 PST 1998 >> Date: Fri, 27 Mar 1998 11:39:52 -0500 >> From: Radhakrishna Sripada >> Organization: Ficon Technology >> To: agentx-request@fv.com >> Subject: Subscribe sripada@ficon-tech.com >> >> Has anyone implemented AGENTX protocol so far as per the RFC2257 ? >> >> >> >> From sar@epilogue.com Fri Mar 27 13:22:13 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA21552 for ; Fri, 27 Mar 1998 13:22:12 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA27279 for ; Fri, 27 Mar 1998 13:21:59 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma026749; Fri, 27 Mar 98 13:20:22 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA19299 for ; Fri, 27 Mar 1998 13:20:00 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma018726; Fri, 27 Mar 98 13:19:36 -0600 Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA15274 for ; Fri, 27 Mar 1998 11:14:26 -0800 (PST) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id NAA05881 for ; Fri, 27 Mar 1998 13:14:24 -0600 (CST) Received: from khitomer.epilogue.com(128.224.1.172) by cashew.bmc.com via smap (V2.0) id xma005868; Fri, 27 Mar 98 13:14:12 -0600 From: "Shawn A. Routhier" Sender: sar@khitomer.epilogue.com To: agentx@peer.com In-reply-to: <199803271758.JAA11601@dorothy.peer.com> (message from Randy Presuhn on Fri, 27 Mar 1998 09:58:00 -0800 (PST)) Subject: Re: fwd: rfc2257 implementation question Date: Fri, 27 Mar 98 14:14:11 -0500 Message-ID: <9803271414.aa26321@khitomer.epilogue.com> > From sripada@ficon-tech.com Fri Mar 27 08:45:04 PST 1998 > Date: Fri, 27 Mar 1998 11:39:52 -0500 > From: Radhakrishna Sripada > Organization: Ficon Technology > To: agentx-request@fv.com > Subject: Subscribe sripada@ficon-tech.com > > Has anyone implemented AGENTX protocol so far as per the RFC2257 ? > We (ISI/Epilogue) have an implementation of the AgentX protocol. Contact me for more info (sar@epilgoue.com). sar From bnatale@acecomm.com Fri Mar 27 13:25:42 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA21602 for ; Fri, 27 Mar 1998 13:25:42 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA28291 for ; Fri, 27 Mar 1998 13:25:27 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma028000; Fri, 27 Mar 98 13:24:10 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA23620 for ; Fri, 27 Mar 1998 13:23:50 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma023122; Fri, 27 Mar 98 13:23:19 -0600 Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA15478 for ; Fri, 27 Mar 1998 11:18:51 -0800 (PST) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id NAA06185 for ; Fri, 27 Mar 1998 13:18:48 -0600 (CST) Received: from relay1.smtp.psi.net(38.8.14.2) by cashew.bmc.com via smap (V2.0) id xma006168; Fri, 27 Mar 98 13:18:19 -0600 Received: from nips.acec.com by relay1.smtp.psi.net (8.8.5/SMI-5.4-PSI) id OAA00681; Fri, 27 Mar 1998 14:18:08 -0500 (EST) Received: from bnatale by nips.acec.com (5.65/3.2.083191-ACE*COMM) id AA21130; Fri, 27 Mar 1998 14:18:19 -0500 Message-Id: <3.0.5.32.19980327142200.00974330@nips.acec.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 27 Mar 1998 14:22:00 -0500 To: Radhakrishna Sripada From: Bob Natale Subject: Re: fwd: rfc2257 implementation question Cc: agentx@peer.com In-Reply-To: <1948721478.891006951@SUBNET86.DYNAMIC.NET.CMU.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 01:55 PM 3/27/98 -0500, Matt White wrote: Hi, >There aren't any available implementations of RFC 2257 yet as far as I know. True as far as I know also. >I'll be releasing an alpha that implements a subset of AgentX sometime >after IETF. It won't be ready for prime time by any means, but it will >give people something to play with. Great. We (ACE*COMM) plan to have our implementation (for Win32 only, over WinSNMP) ready for open beta testing in time for a *possible* "bake-off" type event just prior to or in conjunction with the Chicago IETF in late August. We plan to have completed alpha (May?) and one or more rounds (June and July?) of private beta testing well before then. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ---- WinSNMP DLL, SDK, Apps & Agents for Win16/32 & UNIX ---- ------ NetPlus (r) "FCAPS" Telemanagement Applications ------ From rpresuhn@dorothy.peer.com Sat Mar 28 20:58:19 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id UAA13351 for ; Sat, 28 Mar 1998 20:58:19 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id UAA22527 for ; Sat, 28 Mar 1998 20:58:04 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma022301; Sat, 28 Mar 98 20:56:59 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id UAA01432 for ; Sat, 28 Mar 1998 20:56:38 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma001320; Sat, 28 Mar 98 20:56:14 -0600 Received: (from rpresuhn@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id SAA04367 for agentx@peer.com; Sat, 28 Mar 1998 18:47:42 -0800 (PST) Date: Sat, 28 Mar 1998 18:47:42 -0800 (PST) From: Randy Presuhn Message-Id: <199803290247.SAA04367@dorothy.peer.com> To: agentx@peer.com Subject: Re: fwd: rfc2257 implementation question Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > Date: Fri, 27 Mar 1998 11:39:52 -0500 > From: Radhakrishna Sripada > To: agentx-request@fv.com ... > Has anyone implemented AGENTX protocol so far as per the RFC2257 ? BMC Software has had an implementation (both master and subagent) of the pre-RFC drafts (and, theoretically, RFC 2257) up and running since August, and is patiently waiting for someone to talk to. If you're interested in bakeoffs / interoperability testing, I think Edmund Chang would like to hear from you. ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@peer.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From battle@snmp.com Mon Mar 30 12:04:15 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id MAA14379 for ; Mon, 30 Mar 1998 12:04:15 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA10233 for ; Mon, 30 Mar 1998 12:03:56 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma010084; Mon, 30 Mar 98 12:03:06 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA03430 for ; Mon, 30 Mar 1998 12:02:46 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma002775; Mon, 30 Mar 98 12:02:08 -0600 Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA22887; Mon, 30 Mar 1998 09:51:33 -0800 (PST) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id LAA01520; Mon, 30 Mar 1998 11:51:31 -0600 (CST) Received: from seymour16.snmp.com(192.147.142.16) by cashew.bmc.com via smap (V2.0) id xma001481; Mon, 30 Mar 98 11:50:59 -0600 Received: by seymour16.snmp.com (cf v2.9s-SNMP) id MAA12066; Mon, 30 Mar 1998 12:50:45 -0500 (EST) Date: Mon, 30 Mar 1998 12:50:45 -0500 (EST) From: David Battle Message-Id: <199803301750.MAA12066@seymour16.snmp.com> To: rpresuhn@dorothy.peer.com Subject: Re: fwd: rfc2257 implementation question Cc: agentx@peer.com > up and running since > August, and is patiently waiting for someone to talk to I can't let that one stand. I believe i was begging for someone to test against late last year as well, and got no responses to the email I sent to the list. I can look up the exact date if you like. -David From bnatale@acecomm.com Mon Mar 30 12:39:47 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id MAA14846 for ; Mon, 30 Mar 1998 12:39:47 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA12514 for ; Mon, 30 Mar 1998 12:39:28 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma012325; Mon, 30 Mar 98 12:38:55 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA04408 for ; Mon, 30 Mar 1998 12:38:36 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma003996; Mon, 30 Mar 98 12:38:13 -0600 Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA23048; Mon, 30 Mar 1998 10:32:01 -0800 (PST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA11196; Mon, 30 Mar 1998 12:31:59 -0600 (CST) Received: from relay1.smtp.psi.net(38.8.14.2) by almond.bmc.com via smap (V2.0) id xma011192; Mon, 30 Mar 98 12:31:56 -0600 Received: from nips.acec.com by relay1.smtp.psi.net (8.8.5/SMI-5.4-PSI) id NAA18683; Mon, 30 Mar 1998 13:31:36 -0500 (EST) Received: from bnatale by nips.acec.com (5.65/3.2.083191-ACE*COMM) id AA12485; Mon, 30 Mar 1998 13:31:42 -0500 Message-Id: <3.0.5.32.19980330133526.0095f4d0@nips.acec.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 30 Mar 1998 13:35:26 -0500 To: David Battle , rpresuhn@dorothy.peer.com, "Shawn A. Routhier" , "Matt White" From: Bob Natale Subject: Re: fwd: rfc2257 implementation question Cc: agentx@peer.com In-Reply-To: <199803301750.MAA12066@seymour16.snmp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 12:50 PM 3/30/98 -0500, David Battle wrote: Hi Dave, Randy, Shawn, and Matt: >> up and running since August, and is patiently waiting >> for someone to talk to > >I can't let that one stand. I believe i was begging for >someone to test against late last year as well, and got >no responses to the email I sent to the list. >I can look up the exact date if you like. I think I should step up and take the blame here. Evidently, I was unaware of the level and progress of the implementations underway. I have been monitoring the messages posted to this on this topic and had formed the impression that various implementations were in the works, but i evidently missed the notices of "ready to test" until Shawn and Randy responded on this thread last week. David, I apologize for missing yours--I was aware that SNMP Research was working on it...in fact, much of the most cogent early implementation-oriented feedback came from that effort, but it was (seemed) so long before final issuance of the RFC and with on-going work to the MIB and with something of a drop-off in questions from it (understandable under the circumstances), I guess I put it in the back corners of my mind (getting to be Very Bad Thing to do at my age). Anyway, I've included the four of you in the To: header (sorry for the duplicates) for emphasis, since you four, along with me, have in recent days/weeks/months posted something about the status of your/our implementations. I am aware of other implementations underway that have not been announced by any respective official spokesperson yet, so they will remain anonymous for now. (As soon as you can "go public" on the list, please do.) I guess this leads to three (related) things: 1. Implementation reports. 2. A bake-off. 3. Chicago IETF WG meeting. Working backwards, perhaps we would like to use the Chicago meeting to marshal the implementation and interoperability experience that we will have at that time toward taking the RFC to next level (Draft). This could argue for scheduling the bake-off from one of two angles: a) just prior to the Chicago IETF at a time and place designed to facilitate things for those travelling long distances to attend the IETF in any case; b) some time in advance of the Chicago IETF to allow for fix-ups to implementations, documentation of any generic changes required to RFC2257 or the MIB to ensure interoperability, and for some general recovery and renewal time for those who will attend both meetings. We need to get a consensus on when we should hold the bake-off and the scope/duration of it; and then we can work on who will host it or how it will be funded, etc. So, please post your opinions and/or preferences and/or dates you really cannot make (I realize we're possibly talking about some peak vacation periods here). I have seen some pretty good models for quasi- standardized implementation reports in other WGs in recent months...I will fish around and see if one can be used as a model for AgentX implementation reports. Let's try to wrap up the current round of MIB-related issues, relative to Smitha's recent "-02" posting by April 15. It *seems* like an issue for interoperability testing at the back-off--with the known set of implementations in-progress (probably) being mostly master agents and toolkits--might be "where are the subagents?" Any ideas? > >-David > Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ---- WinSNMP DLL, SDK, Apps & Agents for Win16/32 & UNIX ---- ------ NetPlus (r) "FCAPS" Telemanagement Applications ------ From rpresuhn@dorothy.peer.com Mon Mar 30 16:55:47 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id QAA18231 for ; Mon, 30 Mar 1998 16:55:47 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA00282 for ; Mon, 30 Mar 1998 16:55:29 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma029931; Mon, 30 Mar 98 16:54:10 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA10216 for ; Mon, 30 Mar 1998 16:53:50 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma009543; Mon, 30 Mar 98 16:53:13 -0600 Received: (from rpresuhn@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id OAA00771 for agentx@peer.com; Mon, 30 Mar 1998 14:47:14 -0800 (PST) Date: Mon, 30 Mar 1998 14:47:14 -0800 (PST) From: Randy Presuhn Message-Id: <199803302247.OAA00771@dorothy.peer.com> To: agentx@peer.com Subject: Re: fwd: rfc2257 implementation question Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi David - | Date: Mon, 30 Mar 1998 12:50:45 -0500 (EST) | From: David Battle | To: rpresuhn@dorothy.peer.com | Subject: Re: fwd: rfc2257 implementation question | Cc: agentx@peer.com | | > up and running since | > August, and is patiently waiting for someone to talk to | | I can't let that one stand. I believe i was begging for someone to test | against late last year as well, and got no responses to the email I sent | to the list. | I can look up the exact date if you like. | | -David The folks at this end must have dropped the ball. I've "encouraged" those responsible for AgentX development to get in touch with you directly. If they don't follow through, let me know (privately) and I'll use stronger encouragement. The offer (from previous IETF meetings) of facilities for face-to-face bakeoffs at our Houston offices still stands. ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@peer.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From rpresuhn@dorothy.peer.com Mon Mar 30 17:06:39 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id RAA18376 for ; Mon, 30 Mar 1998 17:06:39 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA01979 for ; Mon, 30 Mar 1998 17:06:21 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma001805; Mon, 30 Mar 98 17:05:26 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA20148 for ; Mon, 30 Mar 1998 17:05:06 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma019502; Mon, 30 Mar 98 17:04:26 -0600 Received: (from rpresuhn@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id OAA00991 for agentx@peer.com; Mon, 30 Mar 1998 14:58:28 -0800 (PST) Date: Mon, 30 Mar 1998 14:58:28 -0800 (PST) From: Randy Presuhn Message-Id: <199803302258.OAA00991@dorothy.peer.com> To: agentx@peer.com Subject: Re: fwd: rfc2257 implementation question Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > Date: Mon, 30 Mar 1998 13:35:26 -0500 > To: David Battle , rpresuhn@dorothy.peer.com, > "Shawn A. Routhier" , "Matt White" > From: Bob Natale > Subject: Re: fwd: rfc2257 implementation question > Cc: agentx@peer.com ... > This could argue for scheduling the bake-off from one > of two angles: a) just prior to the Chicago IETF at > a time and place designed to facilitate things for > those travelling long distances to attend the IETF in > any case; b) some time in advance of the Chicago IETF > to allow for fix-ups to implementations, documentation > of any generic changes required to RFC2257 or the MIB > to ensure interoperability, and for some general > recovery and renewal time for those who will attend > both meetings. I think b) will give us the best hope of progressing, and is probably pretty realistic given the number of implementations and the amount of time they've been around. ... > It *seems* like an issue for interoperability testing > at the back-off--with the known set of implementations cute typo :-) > in-progress (probably) being mostly master agents and > toolkits--might be "where are the subagents?" Any > ideas? ... I don't know how it is for other folks- for us to convert an existing subagent to AgentX is normally a re-link. It'd be great if the MIB work has stabilized by then. ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@peer.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From sgudur@hotmail.com Tue Mar 31 12:20:25 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id MAA03713 for ; Tue, 31 Mar 1998 12:20:24 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA19730 for ; Tue, 31 Mar 1998 12:20:04 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma019488; Tue, 31 Mar 98 12:19:25 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA07312 for ; Tue, 31 Mar 1998 12:19:00 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma007071; Tue, 31 Mar 98 12:18:51 -0600 Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA27495 for ; Tue, 31 Mar 1998 10:06:13 -0800 (PST) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id MAA08504 for ; Tue, 31 Mar 1998 12:06:11 -0600 (CST) Received: from f39.hotmail.com(207.82.250.50) by cashew.bmc.com via smap (V2.0) id xma008489; Tue, 31 Mar 98 12:05:55 -0600 Received: (qmail 12740 invoked by uid 0); 31 Mar 1998 18:05:49 -0000 Message-ID: <19980331180549.12739.qmail@hotmail.com> Received: from 152.67.249.57 by www.hotmail.com with HTTP; Tue, 31 Mar 1998 10:05:49 PST X-Originating-IP: [152.67.249.57] From: "Smitha Gudur" To: agentx@peer.com Subject: tcp and unix address values Content-Type: multipart/mixed; boundary="====================987654321_0==_" Date: Tue, 31 Mar 1998 10:05:49 PST --====================987654321_0==_ Content-Type: text/plain; charset="us-ascii" ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com --====================987654321_0==_ Content-Type: application/octet-stream; name="tran" Content-Transfer-Encoding: x-uuencode Content-Disposition: attachment; filename="tran" begin 644 tran M"E1H:7,@:7,@'1U86P@8V]N=F5N=&EO;B!F;W(@=&-P M(&%N9"!U;FEX(&%D9')E2!F;W(@"@E)4"!V-CH)(C%D M+C%D+C%D+C%D+C%D+C%D+S)D(B`*"G1H96X@:&]W('=I;&P@=&AI'1U M86P@8V]N=F5N=&EO;B!F;W(@=&AIV%G96YT>$]B:F5C=',@-7T*86=E M;G1X54Y)6$1O;6%I;B`@3T)*14-4($E$14Y4249)15(@.CH]('MA9V5N='A/ M8FIE8W1S(#9]"@H*86=E;G1X5$-0061D$-O;FYE8W1I;VY%;G1R>2`S('T*(`IA9V5N='A#;VYN5')A;G-P M;W)T061D$-O;FYE8W1I;VY%;G1R>2`T('T*"@IS M96YD(&EN<'5T Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id MAA04045 for ; Tue, 31 Mar 1998 12:45:32 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA22108 for ; Tue, 31 Mar 1998 12:45:13 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma021824; Tue, 31 Mar 98 12:44:27 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA00756 for ; Tue, 31 Mar 1998 12:44:07 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma000195; Tue, 31 Mar 98 12:43:36 -0600 Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA27652 for ; Tue, 31 Mar 1998 10:38:35 -0800 (PST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA20711 for ; Tue, 31 Mar 1998 12:38:34 -0600 (CST) Received: from relay1.smtp.psi.net(38.8.14.2) by almond.bmc.com via smap (V2.0) id xma020704; Tue, 31 Mar 98 12:38:04 -0600 Received: from nips.acec.com by relay1.smtp.psi.net (8.8.5/SMI-5.4-PSI) id NAA11093; Tue, 31 Mar 1998 13:38:02 -0500 (EST) Received: from bnatale by nips.acec.com (5.65/3.2.083191-ACE*COMM) id AA29190; Tue, 31 Mar 1998 13:38:10 -0500 Message-Id: <3.0.5.32.19980331134155.0097d870@nips.acec.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 31 Mar 1998 13:41:55 -0500 To: agentx@peer.com From: Bob Natale Subject: tcp and unix address values Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" [Re-posting in case anyone else had trouble with the attachment - BobN] This is regarding textual convention for tcp and unix addresses. As IP v6 has 6 bytes for address, should we define TCP address in terms of IP v6? If we were to define in terms of IP v6, then the display for IP v6: "1d.1d.1d.1d.1d.1d/2d" then how will this look for IP v4? should we have a different textual convention for this? I have defined object identifiers and its textual conventions in terms of IP version 4. agentxTCPDomain OBJECT IDENTIFIER ::= {agentxObjects 5} agentxUNIXDomain OBJECT IDENTIFIER ::= {agentxObjects 6} agentxTCPAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d.1d.1d.1d/2d" STATUS current DESCRIPTION "Represents a TCP address." SYNTAX OCTET STRING (SIZE (6)) agentxUNIXAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d.1d.1d.1d/2d" STATUS current DESCRIPTION "Represents a UNIX domain socket address." SYNTAX OCTET STRING (SIZE (6)) agentxConnTransportDomain OBJECT-TYPE SYNTAX TDomain MAX-ACCESS read-only STATUS current DESCRIPTION "The transport protocol in use for this connection to the master agent." ::= { agentxConnectionEntry 3 } agentxConnTransportAddress OBJECT-TYPE SYNTAX TAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The transport address of the remote (subagent) end of this connection to the master agent. This is formatted according to the corresponding value of agentxConnTransportDomain." ::= { agentxConnectionEntry 4 } send inputs to agentx mailing list. thanks smitha From schoenw@ibr.cs.tu-bs.de Tue Mar 31 16:11:40 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id QAA06765 for ; Tue, 31 Mar 1998 16:11:40 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA04448 for ; Tue, 31 Mar 1998 16:11:19 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma004255; Tue, 31 Mar 98 16:10:44 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA27393 for ; Tue, 31 Mar 1998 16:10:24 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma026876; Tue, 31 Mar 98 16:09:58 -0600 Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA03610 for ; Tue, 31 Mar 1998 14:02:07 -0800 (PST) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id QAA21344 for ; Tue, 31 Mar 1998 16:02:04 -0600 (CST) Received: from ra.ibr.cs.tu-bs.de(134.169.34.12) by cashew.bmc.com via smap (V2.0) id xma021305; Tue, 31 Mar 98 16:01:33 -0600 Received: from henkell.ibr.cs.tu-bs.de (henkell [134.169.34.191]) by ra.ibr.cs.tu-bs.de (8.8.6/8.8.6) with ESMTP id AAA04950; Wed, 1 Apr 1998 00:01:30 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id AAA04276; Wed, 1 Apr 1998 00:01:28 +0200 Date: Wed, 1 Apr 1998 00:01:28 +0200 Message-Id: <199803312201.AAA04276@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: bnatale@acecomm.com CC: agentx@peer.com In-reply-to: <3.0.5.32.19980331134155.0097d870@nips.acec.com> (message from Bob Natale on Tue, 31 Mar 1998 13:41:55 -0500) Subject: Re: tcp and unix address values References: <3.0.5.32.19980331134155.0097d870@nips.acec.com> >>>>> Bob Natale writes: Bob> This is regarding textual convention for tcp and unix addresses. Bob> As IP v6 has 6 bytes for address, should we define TCP address in Bob> terms of IP v6? [snip] These things should IMHO be defined in an annex to RFC 1903, as discussed in the SNMPv3 meeting today. These definitions are needed by several MIBs, not only AgentX. Other than that, I think the definition of agentxUNIXAddress does not work. BTW, has someone contacts to POSIX folks? I have hear rumors that they will define something like posix domain sockets, just to avoid the word UNIX. We should probably try to align our terminology if there is serious work to standardize UNIX sockets within POSIX. Juergen -- Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3283) From bnatale@acecomm.com Tue Mar 31 16:48:24 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id QAA07251 for ; Tue, 31 Mar 1998 16:48:24 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA07908 for ; Tue, 31 Mar 1998 16:48:03 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma007652; Tue, 31 Mar 98 16:46:55 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA04737 for ; Tue, 31 Mar 1998 16:46:34 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma004137; Tue, 31 Mar 98 16:45:59 -0600 Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA11870 for ; Tue, 31 Mar 1998 14:41:39 -0800 (PST) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id QAA23574 for ; Tue, 31 Mar 1998 16:41:37 -0600 (CST) Received: from relay1.smtp.psi.net(38.8.14.2) by cashew.bmc.com via smap (V2.0) id xma023561; Tue, 31 Mar 98 16:41:33 -0600 Received: from nips.acec.com by relay1.smtp.psi.net (8.8.5/SMI-5.4-PSI) id RAA23247; Tue, 31 Mar 1998 17:41:29 -0500 (EST) Received: from bnatale by nips.acec.com (5.65/3.2.083191-ACE*COMM) id AA03332; Tue, 31 Mar 1998 17:41:38 -0500 Message-Id: <3.0.5.32.19980331174523.009a2e00@nips.acec.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 31 Mar 1998 17:45:23 -0500 To: Juergen Schoenwaelder From: Bob Natale Subject: Re: tcp and unix address values Cc: agentx@peer.com In-Reply-To: <199803312201.AAA04276@henkell.ibr.cs.tu-bs.de> References: <3.0.5.32.19980331134155.0097d870@nips.acec.com> <3.0.5.32.19980331134155.0097d870@nips.acec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 12:01 AM 4/1/98 +0200, Juergen Schoenwaelder wrote: Hi Juergen (and Smitha! :-), >>>>>> Bob Natale writes: > >Bob> This is regarding textual convention for tcp and unix addresses. >Bob> As IP v6 has 6 bytes for address, should we define TCP address in >Bob> terms of IP v6? > >[snip] I apologize...I failed to make it clear that I was merely re-posting a message from Smitha. (I saw some potential problems with the format of the attachment in her original and just dumped it as text into the re-post.) Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ---- WinSNMP DLL, SDK, Apps & Agents for Win16/32 & UNIX ---- ------ NetPlus (r) "FCAPS" Telemanagement Applications ------