From daniele@zk3.dec.com Wed Apr 1 10:07:51 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 KAA20995 for ; Wed, 1 Apr 1998 10:07:51 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA19891 for ; Wed, 1 Apr 1998 10:07:29 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma019556; Wed, 1 Apr 98 10:06:04 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id KAA11992 for ; Wed, 1 Apr 1998 10:05:44 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma011258; Wed, 1 Apr 98 10:05:07 -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 HAA03803 for ; Wed, 1 Apr 1998 07:57:36 -0800 (PST) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id JAA06705 for ; Wed, 1 Apr 1998 09:57:30 -0600 (CST) Received: from mail12.digital.com(192.208.46.20) by cashew.bmc.com via smap (V2.0) id xma006662; Wed, 1 Apr 98 09:57:01 -0600 Received: from flume.zk3.dec.com (flume.zk3.dec.com [16.140.112.3]) by mail12.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id KAA06228 for ; Wed, 1 Apr 1998 10:56:53 -0500 (EST) Received: from bernie.zk3.dec.com by flume.zk3.dec.com (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA23109; Wed, 1 Apr 1998 10:56:46 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA13769; Wed, 1 Apr 1998 10:54:18 -0500 Message-Id: <9804011554.AA13769@bernie.zk3.dec.com> To: agentx@peer.com Subject: Re: tcp and unix address values In-Reply-To: Your message of "Tue, 31 Mar 98 13:41:55 EST." <3.0.5.32.19980331134155.0097d870@nips.acec.com> Date: Wed, 01 Apr 98 10:54:18 -0500 From: Mike Daniele X-Mts: smtp Hi, >[Re-posting in case anyone else had trouble with the attachment - BobN] Thanks Bob. Smitha said: >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" Fyi, I posted suggested IPv6 changes to RFC 1906 to the SNMPv3 list a while back. Hopefully they will be a useful reference. -- SNMPv2 over UDP over IPv6 snmpUDPv6Domain OBJECT-IDENTITY STATUS current DESCRIPTION "The SNMPv2 over UDP over IPv6 transport domain. The corresponding transport address is of type SnmpUDPv6Address." ::= { snmpDomains 6 } SnmpUDPv6Address ::= TEXTUAL-CONVENTION DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x/2d" STATUS current DESCRIPTION "Represents a UDP over IPv6 address: octets contents encoding 1-16 IPv6-address network-byte order 17-18 UDP-port network-byte order " SYNTAX OCTET STRING (SIZE (18)) Juergen said: >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. I'm not attending the current IETF, so don't know what happened in the meeting. But I agree with this statement. I'd like to see (at least) TCP and UDP over IPv4 and v6 defined in the SNMPv2/3 infrastructure somewhere. UNIX domain sockets probably wouldn't be considered appropriate for such inclusion... >Other than that, I think the definition of agentxUNIXAddress does not >work. You're right. A UNIX domain socket endpoint is a file name, not an IP address. (RFC 2257 specifies the master bind to "/var/agentx/master".) So the TAddress defined for it has to be variable length. Something like this: UNIXTCPAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT ??? STATUS current DESCRIPTION "Represents a TCP over UNIX-domain sockets endpoint: octets contents encoding 1 to (n-2) UNIX domain address string (n-1) to n  TCP-port network-byte order where 'n' is the total length of the OCTET STRING. " SYNTAX OCTET STRING >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. We have some folks who should know this, I'll try and track it down. Regards, Mike From schoenw@ibr.cs.tu-bs.de Thu Apr 2 00:40: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 AAA02520 for ; Thu, 2 Apr 1998 00:40:49 -0600 (CST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id AAA02758 for ; Thu, 2 Apr 1998 00:40:26 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma002422; Thu, 2 Apr 98 00:39:26 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id AAA25241 for ; Thu, 2 Apr 1998 00:39:07 -0600 (CST) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma025088; Thu, 2 Apr 98 00:38:56 -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 WAA15837 for ; Wed, 1 Apr 1998 22:32:03 -0800 (PST) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id AAA01411 for ; Thu, 2 Apr 1998 00:32:02 -0600 (CST) Received: from ra.ibr.cs.tu-bs.de(134.169.34.12) by almond.bmc.com via smap (V2.0) id xma001396; Thu, 2 Apr 98 00:31:38 -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 IAA15699; Thu, 2 Apr 1998 08:31:36 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id IAA07690; Thu, 2 Apr 1998 08:31:35 +0200 Date: Thu, 2 Apr 1998 08:31:35 +0200 Message-Id: <199804020631.IAA07690@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: daniele@zk3.dec.com CC: agentx@peer.com In-reply-to: <9804011554.AA13769@bernie.zk3.dec.com> (message from Mike Daniele on Wed, 01 Apr 98 10:54:18 -0500) Subject: Re: tcp and unix address values References: <9804011554.AA13769@bernie.zk3.dec.com> >>>>> Mike Daniele writes: Mike> I'm not attending the current IETF, so don't know what happened Mike> in the meeting. But I agree with this statement. I'd like to Mike> see (at least) TCP and UDP over IPv4 and v6 defined in the Mike> SNMPv2/3 infrastructure somewhere. There was a discussion to start a series of addendums to 1903 which define additional frequently used TCs. This allows to progress 1903 while giving us a central place to collect all those transport address definition, UTF8 strings, owner strings, ... that we have right now spread over several documents. There will be a set of workplans for all these action items that will hopefully appear on the SNMPv3 mailing list soon so that we can do these things quickly enough to not delay any of the MIBs currently being finished. Wait for the meeting minutes for all the rest that happened in the SNMPv3 meeting. 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 Apr 7 14:06: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 OAA03174 for ; Tue, 7 Apr 1998 14:06:58 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA22013 for ; Tue, 7 Apr 1998 14:06:24 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma021752; Tue, 7 Apr 98 14:05:31 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA04397 for ; Tue, 7 Apr 1998 14:05:09 -0500 (CDT) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma003884; Tue, 7 Apr 98 14:04:40 -0500 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 LAA26967 for ; Tue, 7 Apr 1998 11:51:18 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA20040 for ; Tue, 7 Apr 1998 13:51:17 -0500 (CDT) Received: from relay1.smtp.psi.net(38.8.14.2) by almond.bmc.com via smap (V2.0) id xma019959; Tue, 7 Apr 98 13:50:43 -0500 Received: from nips.acec.com by relay1.smtp.psi.net (8.8.5/SMI-5.4-PSI) id OAA29412; Tue, 7 Apr 1998 14:50:28 -0400 (EDT) Received: from bnatale by nips.acec.com (5.65/3.2.083191-ACE*COMM) id AA02478; Tue, 7 Apr 1998 14:50:27 -0400 Message-Id: <3.0.5.32.19980407145420.009a0da0@nips.acec.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 07 Apr 1998 14:54:20 -0400 To: agentx@peer.com From: Bob Natale Subject: AgentX bake-off - going once? In-Reply-To: <199803302247.OAA00771@dorothy.peer.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 02:47 PM 3/30/98 -0800, Randy Presuhn wrote: Hi everyone, <...> >The offer (from previous IETF meetings) of facilities for >face-to-face bakeoffs at our Houston offices still stands. Ok...thanks, Randy. I guess we should start planning for this event. We need to fix on the date(s), place, and scope. This posting is just a "feeler" to elicit either general agreement or alternatives for the basic logistics. We can hammer out the finer details of scope a bit later (but feel free to comment on that whenever you want). Barring any alternative offers for consideration, we will accept the BMC/Peer offer of facilities in Houston. The only downsides I can see to that are: - Houston weather (if memory serves me correctly) can be, errr, painful in the summer. - The location may impose a travel burden on those from Europe who may want to attend. On the positive side, I am sure that the facilities will be technically (and otherwise!) superb and Houston is generally equally accessible from just about every region of the US. As far as dates go, my *personal* preference is for late July. Other opinios, preferences, offers, suggestions? 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 Lauren_Heintz@bmc.com Tue Apr 7 16:37: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 QAA05123 for ; Tue, 7 Apr 1998 16:37:31 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA03244 for ; Tue, 7 Apr 1998 16:36:57 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma003192; Tue, 7 Apr 98 16:36:48 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA21402 for ; Tue, 7 Apr 1998 16:36:26 -0500 (CDT) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma021157; Tue, 7 Apr 98 16:36:07 -0500 Received: from cherry.bmc.com (root@cherry.bmc.com [172.17.1.25]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA04571 for ; Tue, 7 Apr 1998 14:25:08 -0700 (PDT) Received: from lucille.peer.com (lucille.peer.com [192.146.153.185]) by cherry.bmc.com with SMTP (8.7.5/8.7.3) id QAA18498; Tue, 7 Apr 1998 16:25:03 -0500 (CDT) Message-ID: <352A991E.286E@bmc.com> Date: Tue, 07 Apr 1998 14:22:38 -0700 From: Lauren Heintz Reply-To: Lauren_Heintz@bmc.com Organization: Peer X-Mailer: Mozilla 3.03 (Win95; I) MIME-Version: 1.0 To: bnatale@acecomm.com CC: agentx@peer.com, snmpv3@tis.com, Ned Corry , Edmund Chang Subject: Re: AgentX bake-off - going once? References: <3.0.5.32.19980407145420.009a0da0@nips.acec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, Randy asked me to respond to Bob's message.... We very much support the notion of having agentx bake-off for late July in our Houston offices. Also, we would like to suggest that we combine the SNMPv3 bakeoff into the same event (thus, this cross-post to the snmpv3 list). This would help minimize travel expenses for everyone and possibly assure wider attendance, and such. Regarding weather concerns, I can assure you that the BMC offices, the area hotels, and the rental cars are all air-conditioned. :-) Lauren bnatale@acecomm.com wrote: > > >At 02:47 PM 3/30/98 -0800, Randy Presuhn wrote: > > Hi everyone, > > <...> > >The offer (from previous IETF meetings) of facilities for > >face-to-face bakeoffs at our Houston offices still stands. > > Ok...thanks, Randy. I guess we should start planning for > this event. We need to fix on the date(s), place, and > scope. This posting is just a "feeler" to elicit either > general agreement or alternatives for the basic logistics. > We can hammer out the finer details of scope a bit later > (but feel free to comment on that whenever you want). > > Barring any alternative offers for consideration, we > will accept the BMC/Peer offer of facilities in Houston. > The only downsides I can see to that are: > > - Houston weather (if memory serves me correctly) > can be, errr, painful in the summer. > > - The location may impose a travel burden on those > from Europe who may want to attend. > > On the positive side, I am sure that the facilities will > be technically (and otherwise!) superb and Houston is > generally equally accessible from just about every region > of the US. > > As far as dates go, my *personal* preference is for late > July. > > Other opinios, preferences, offers, suggestions? > > 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 ------ -- --------------------------------------------------------------------- Lauren Heintz BMC Software, Inc. (Silicon Valley Division) Voice: +1 408 616-3169 (Formerly PEER Networks) http://www.bmc.com Fax: +1 408 616-3339 965 Stewart Drive Email: Lheintz@bmc.com Sunnyvale, California 94086 USA --------------------------------------------------------------------- My opinions are my own and not necessarily those of BMC Software. --------------------------------------------------------------------- From rpresuhn@dorothy.peer.com Tue Apr 14 11:24: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 LAA02130 for ; Tue, 14 Apr 1998 11:24:01 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA03500 for ; Tue, 14 Apr 1998 11:23:15 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma003085; Tue, 14 Apr 98 11:22:12 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA14243 for ; Tue, 14 Apr 1998 11:21:51 -0500 (CDT) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma013874; Tue, 14 Apr 98 11:21:37 -0500 Received: (from rpresuhn@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id JAA15589 for agentx@peer.com; Tue, 14 Apr 1998 09:08:17 -0700 (PDT) Date: Tue, 14 Apr 1998 09:08:17 -0700 (PDT) From: Randy Presuhn Message-Id: <199804141608.JAA15589@dorothy.peer.com> To: agentx@peer.com Subject: agentx API work Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - I see the program for next week's IEEE systems management workshop includes a work-in-progress session on rapid agent development. (http://www.csd.uwo.ca/conf/smw3.html) It might be interesting to see how this fits in with agentx API work. Is anyone else currently doing anything along those lines? ----------------------------------------------------------------------- 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 rafaelv@istar.ca Wed Apr 15 00:11: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 AAA12270 for ; Wed, 15 Apr 1998 00:11:26 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id AAA08052 for ; Wed, 15 Apr 1998 00:10:40 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma007708; Wed, 15 Apr 98 00:09:40 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id AAA25424 for ; Wed, 15 Apr 1998 00:09:19 -0500 (CDT) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma025260; Wed, 15 Apr 98 00:09:09 -0500 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 WAA09339 for ; Tue, 14 Apr 1998 22:04:15 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id AAA06775 for ; Wed, 15 Apr 1998 00:04:14 -0500 (CDT) Received: from mail1.toronto.istar.net(209.89.75.17) by almond.bmc.com via smap (V2.0) id xma006767; Wed, 15 Apr 98 00:04:11 -0500 Received: from ts78-03.tor.istar.ca (istar.ca) [204.191.146.114] by mail1.toronto.istar.net with esmtp (Exim 1.80 #5) id 0yPKQH-0002jV-00; Wed, 15 Apr 1998 01:07:50 -0400 Message-ID: <3532E116.14C88BC4@istar.ca> Date: Mon, 13 Apr 1998 22:07:51 -0600 From: "Rafael A. Valencia" Reply-To: rafaelv@istar.ca Organization: CNS X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: agentx@peer.com Subject: (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit subscribe rafaelv@istar.ca From cclark@cnri.reston.va.us Thu Apr 16 09:13: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 JAA08500 for ; Thu, 16 Apr 1998 09:13:05 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id JAA04097 for ; Thu, 16 Apr 1998 09:12:16 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma003800; Thu, 16 Apr 98 09:11:17 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id JAA13283 for ; Thu, 16 Apr 1998 09:10:56 -0500 (CDT) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma013019; Thu, 16 Apr 98 09:10:42 -0500 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 GAA18247 for ; Thu, 16 Apr 1998 06:58:32 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id IAA04738 for ; Thu, 16 Apr 1998 08:58:30 -0500 (CDT) Received: from ietf.org(132.151.1.19) by cashew.bmc.com via smap (V2.0) id xma004725; Thu, 16 Apr 98 08:58:17 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id JAA03090; Thu, 16 Apr 1998 09:44:34 -0400 (EDT) Message-Id: <199804161344.JAA03090@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: agentx@peer.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-agentx-mib-02.txt Date: Thu, 16 Apr 1998 09:44:34 -0400 Sender: cclark@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SNMP Agent Extensibility Working Group of the IETF. Title : Definitions of Managed Objects for Extensible SNMP Agents Author(s) : M. Greene, S. Gudur Filename : draft-ietf-agentx-mib-02.txt Pages : 18 Date : 15-Apr-98 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. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-agentx-mib-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-agentx-mib-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-agentx-mib-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980415173543.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-agentx-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-agentx-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980415173543.I-D@ietf.org> --OtherAccess-- --NextPart-- From schoenw@ibr.cs.tu-bs.de Thu Apr 16 11:21:52 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 LAA10227 for ; Thu, 16 Apr 1998 11:21:52 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA12680 for ; Thu, 16 Apr 1998 11:21:02 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma012433; Thu, 16 Apr 98 11:19:50 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA02057 for ; Thu, 16 Apr 1998 11:19:29 -0500 (CDT) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma001467; Thu, 16 Apr 98 11:18:54 -0500 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 JAA18694 for ; Thu, 16 Apr 1998 09:13:58 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA11188 for ; Thu, 16 Apr 1998 11:13:56 -0500 (CDT) Received: from ra.ibr.cs.tu-bs.de(134.169.34.12) by almond.bmc.com via smap (V2.0) id xma011163; Thu, 16 Apr 98 11:13:29 -0500 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 SAA12542; Thu, 16 Apr 1998 18:12:20 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id SAA15193; Thu, 16 Apr 1998 18:12:08 +0200 Date: Thu, 16 Apr 1998 18:12:08 +0200 Message-Id: <199804161612.SAA15193@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: agentx@peer.com CC: bnatale@acec.com, mundy@tis.com, wijnen@vnet.ibm.com, Harald.Alvestrand@maxware.no In-reply-to: <199804161344.JAA03090@ns.ietf.org> (Internet-Drafts@ietf.org) Subject: Re: I-D ACTION:draft-ietf-agentx-mib-02.txt References: <199804161344.JAA03090@ns.ietf.org> Nice to see the current AgentX MIB being published as an ID. I have found the following minor problem while compiling the MIB: The AGENTX-MIB imports TDomain and TAddress from SNMPv2-SMI, which is not correct. TDomain and TAddress are defined in SNMPv2-TC. I am still concerned to see definitions for Utf8String (which is already similarily defined in RFC 2287) and AgentxTCPAddress in this MIB. I think they should be moved to an RFC 1903 addendum, as discussed in the SNMPv3 meeting in LA. This also affects the IPv6 TC definitions posted to the SNMPv3 mailing list a few weeks ago. The problem is that this addendum will most likely be done by the SNMPv3 WG (or even a special SMIv2 WG) and that this might delay other MIBs that want to use this stuff. So we need to get the responsible people (WG chairman and ADs) to figure out quickly how this is going to be done in a timely manner. I will certainly volunteer to collect reusable definitions from various IDs and to put them together into an RFC 1903 addendum ID, if people want this to happen. However, I first need a signal from the "officials" (people in the CC list) that this is the way to proceed and where this stuff belongs to. 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 info@cigi.com Wed Apr 22 01:48: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 BAA13316 for ; Wed, 22 Apr 1998 01:48:17 -0500 (CDT) From: info@cigi.com Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id BAA00145 for ; Wed, 22 Apr 1998 01:47:17 -0500 (CDT) Received: from dresden.bmc.com(198.64.253.250) by almond.bmc.com via smap (V2.0) id xma029777; Wed, 22 Apr 98 01:45:54 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id BAA20222 for ; Wed, 22 Apr 1998 01:45:29 -0500 (CDT) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma020020; Wed, 22 Apr 98 01:45:15 -0500 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 XAA19147 for ; Tue, 21 Apr 1998 23:37:41 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id BAA28647 for ; Wed, 22 Apr 1998 01:37:40 -0500 (CDT) Received: from darius.concentric.net(207.155.184.79) by almond.bmc.com via smap (V2.0) id xma028643; Wed, 22 Apr 98 01:37:23 -0500 Received: from newman.concentric.net (newman.concentric.net [207.155.184.71]) by darius.concentric.net (8.8.8/(98/01/20 5.9)) id CAA10873; Wed, 22 Apr 1998 02:37:22 -0400 (EDT) [1-800-745-2747 The Concentric Network] Errors-To: Received: from cigi.com (ts013d37.hil-ny.concentric.net [206.173.17.145]) by newman.concentric.net (8.8.8) id CAA26721; Wed, 22 Apr 1998 02:37:21 -0400 (EDT) Date: Wed, 22 Apr 1998 02:37:21 -0400 (EDT) Message-Id: <199804220637.CAA26721@newman.concentric.net> To: agentx@peer.com Subject: Shopping Cart - Free Demo Hello, Thought you may be interested in installing a shopping cart to help better service your customers. The shopping cart can be easily modified to suit your website. If you are interested in seeing how this works you can go to my demo shops at: http://www.webjunkie.com/tvmatters/index.html AND http://www.webjunkie.com/cashcart/index.html This cart is loaded with many features, it even comes with a built in search engine. If you would like to find out more about the carts features, you can go to: http://www.webjunkie.com/cashcart/features.html It won't cost you anything but some time and your commitment to get started. We do not ask for any payments up front, all we ask is that you meet the following requirements: 1) Your pages must be hosted on a UNIX type server. (Will work on anything but an NT server) 2) You are serious about purchasing a Shopping Cart to enhance your website. Thats it. If you meet the above requirements, and are ready to add a Shopping Cart to your website, contact us today so we can get started on your working demo. This demo will be created from your own online catalog and will be used as your templates. When you are satisfied with the performance of your working demo and are ready to transfer it over to your server, that is when we ask for payment. PRICES Shopping Cart Program, Manual, $250.00 and Tech Support. Shopping Cart Program, Manual, Installation and Tech Support. $425.00 Once we receive payment we will install the Shopping Cart on your server, or provide you with detailed instructions on how to do it yourself, the choice is yours. You will also receive your templates and instructions on how to use them. If you get stuck along the way, we offer tech support via phone or e-mail, for as long as you need it. If you are interested in taking your website to the "next level", or if you have any questions, please, contact me at info@cigi.com Thanks, Eric Webjunkie Productions http://www.webjunkie.com From daniele@zk3.dec.com Mon Apr 27 13:10:36 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 NAA10198 for ; Mon, 27 Apr 1998 13:10:31 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA14466 for ; Mon, 27 Apr 1998 13:09:20 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma014246; Mon, 27 Apr 98 13:08:18 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA21071 for ; Mon, 27 Apr 1998 13:07:52 -0500 (CDT) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma020698; Mon, 27 Apr 98 13:07:34 -0500 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 KAA23858 for ; Mon, 27 Apr 1998 10:50:39 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA12589 for ; Mon, 27 Apr 1998 12:50:37 -0500 (CDT) Received: from mail13.digital.com(192.208.46.30) by almond.bmc.com via smap (V2.0) id xma012552; Mon, 27 Apr 98 12:50:26 -0500 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.0d) with SMTP id NAA01169 for ; Mon, 27 Apr 1998 13:50:17 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA25077; Mon, 27 Apr 1998 13:50:13 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA30609; Mon, 27 Apr 1998 13:47:49 -0400 Message-Id: <9804271747.AA30609@bernie.zk3.dec.com> To: agentx@peer.com Subject: Re: tcp and unix address values Date: Mon, 27 Apr 98 13:47:48 -0400 From: Mike Daniele X-Mts: smtp Earlier Juergen had asked >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. and I replied >We have some folks who should know this, I'll try and track it down. Well, I tried to track it down. To the best of my knowledge there is no move away from the term "UNIX domain socket". Mike From schoenw@ibr.cs.tu-bs.de Tue Apr 28 05:27:52 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 FAA22667 for ; Tue, 28 Apr 1998 05:27:52 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id FAA26416 for ; Tue, 28 Apr 1998 05:26:41 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma026409; Tue, 28 Apr 98 05:26:22 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id FAA09271 for ; Tue, 28 Apr 1998 05:25:58 -0500 (CDT) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma009163; Tue, 28 Apr 98 05:25:27 -0500 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 DAA26312 for ; Tue, 28 Apr 1998 03:18:18 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id FAA27610 for ; Tue, 28 Apr 1998 05:18:17 -0500 (CDT) Received: from ra.ibr.cs.tu-bs.de(134.169.34.12) by cashew.bmc.com via smap (V2.0) id xma027601; Tue, 28 Apr 98 05:17:53 -0500 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 MAA12138; Tue, 28 Apr 1998 12:17:45 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id MAA22362; Tue, 28 Apr 1998 12:17:44 +0200 Date: Tue, 28 Apr 1998 12:17:44 +0200 Message-Id: <199804281017.MAA22362@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: agentx@peer.com Subject: index allocation Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Let assume I want to allocate an index for ifTable. I set the NEW_INDEX flag because I want a new index not previously allocated. I set v.type to Integer and v.data to some arbitrary value. The question is: What is the correct value for v.name? Is it the OID for ifIndex or do I have to provide a pseude instance identifier, e.g. ifIndex.0? Now, lets assume I want to allocate an index for fooTable, indexed by fooIndex. This time, I do not set NEW_INDEX nor ANY_INDEX. (So v.data is the index I would like to have allocated.) Does the OID for v.name contain an instance identifer (v.data) or not? What happens if the instance identifier is there but does not match v.data? I guess v.name must have an instance identifier in all cases, even if it is ignored in some cases. However, the description in RFC 2257 does not tell me precisely what a subagent is supposed to put into an agentx-IndexAllocate-PDU. (A master can only guess whether there is an instance identifier or not without having MIB knowledge.) Juergen From daniele@zk3.dec.com Tue Apr 28 08:18:55 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 IAA24882 for ; Tue, 28 Apr 1998 08:18:54 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id IAA03443 for ; Tue, 28 Apr 1998 08:17:43 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma003323; Tue, 28 Apr 98 08:17:20 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id IAA07155 for ; Tue, 28 Apr 1998 08:16:57 -0500 (CDT) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma007092; Tue, 28 Apr 98 08:16:55 -0500 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 GAA26630 for ; Tue, 28 Apr 1998 06:10:00 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id IAA01993 for ; Tue, 28 Apr 1998 08:09:58 -0500 (CDT) Received: from mail13.digital.com(192.208.46.30) by almond.bmc.com via smap (V2.0) id xma001989; Tue, 28 Apr 98 08:09:57 -0500 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.0d) with SMTP id JAA22845; Tue, 28 Apr 1998 09:09:25 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA25206; Tue, 28 Apr 1998 09:09:23 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA32053; Tue, 28 Apr 1998 09:07:05 -0400 Message-Id: <9804281307.AA32053@bernie.zk3.dec.com> To: Juergen Schoenwaelder Cc: agentx@peer.com Subject: Re: index allocation In-Reply-To: Your message of "Tue, 28 Apr 98 12:17:44 +0200." <199804281017.MAA22362@henkell.ibr.cs.tu-bs.de> Date: Tue, 28 Apr 98 09:07:05 -0400 From: Mike Daniele X-Mts: smtp Juergen asked: >Let assume I want to allocate an index for ifTable. I set the >NEW_INDEX flag because I want a new index not previously allocated. I >set v.type to Integer and v.data to some arbitrary value. The question >is: What is the correct value for v.name? Is it the OID for ifIndex or >do I have to provide a pseude instance identifier, e.g. ifIndex.0? I would expect the oid prefix `ifIndex'. >Now, lets assume I want to allocate an index for fooTable, indexed by >fooIndex. This time, I do not set NEW_INDEX nor ANY_INDEX. (So v.data >is the index I would like to have allocated.) Does the OID for v.name >contain an instance identifer (v.data) or not? What happens if the >instance identifier is there but does not match v.data? Again, v.name should be the oid prefix `fooIndex'. >I guess v.name must have an instance identifier in all cases, even if >it is ignored in some cases. My thinking was that v.name would never containing instance information, it would always be the oid prefix of an index object. That just seemed the simplest. >However, the description in RFC 2257 does >not tell me precisely what a subagent is supposed to put into an >agentx-IndexAllocate-PDU. (A master can only guess whether there is >an instance identifier or not without having MIB knowledge.) You are correct, the text in 7.1.2 and 7.1.3 should be clearer about the contents of v.name. Mike From sar@epilogue.com Tue Apr 28 13:22: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 NAA28817 for ; Tue, 28 Apr 1998 13:22:37 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA23109 for ; Tue, 28 Apr 1998 13:21:26 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma023071; Tue, 28 Apr 98 13:21:11 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA11189 for ; Tue, 28 Apr 1998 13:20:47 -0500 (CDT) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma010980; Tue, 28 Apr 98 13:20:37 -0500 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 LAA28380 for ; Tue, 28 Apr 1998 11:09:40 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id NAA24778 for ; Tue, 28 Apr 1998 13:09:38 -0500 (CDT) Received: from khitomer.epilogue.com(128.224.1.172) by cashew.bmc.com via smap (V2.0) id xma024759; Tue, 28 Apr 98 13:09:29 -0500 From: "Shawn A. Routhier" Sender: sar@khitomer.epilogue.com To: daniele@zk3.dec.com CC: schoenw@ibr.cs.tu-bs.de, agentx@peer.com In-reply-to: <9804281307.AA32053@bernie.zk3.dec.com> (message from Mike Daniele on Tue, 28 Apr 98 09:07:05 -0400) Subject: Re: index allocation Date: Tue, 28 Apr 98 14:09:18 -0400 Message-ID: <9804281409.aa17819@khitomer.epilogue.com> Cc: agentx@peer.com Date: Tue, 28 Apr 98 09:07:05 -0400 From: Mike Daniele X-Mts: smtp Juergen asked: About what the proper OID for v.name is during index allocation. Mike Daniele replied: That he expected that v.name would be the oid prefix for the object. I interpreted RFC2257 in the same fashion as Mike did. sar From schoenw@ibr.cs.tu-bs.de Tue Apr 28 14:19:56 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 OAA29559 for ; Tue, 28 Apr 1998 14:19:55 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA27298 for ; Tue, 28 Apr 1998 14:18:44 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma027274; Tue, 28 Apr 98 14:18:14 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA15245 for ; Tue, 28 Apr 1998 14:17:50 -0500 (CDT) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma014651; Tue, 28 Apr 98 14:17:19 -0500 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 MAA29347 for ; Tue, 28 Apr 1998 12:10:42 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id OAA28553 for ; Tue, 28 Apr 1998 14:10:40 -0500 (CDT) Received: from ra.ibr.cs.tu-bs.de(134.169.34.12) by cashew.bmc.com via smap (V2.0) id xma028541; Tue, 28 Apr 98 14:10:21 -0500 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 VAA25544; Tue, 28 Apr 1998 21:10:11 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id VAA24910; Tue, 28 Apr 1998 21:10:09 +0200 Date: Tue, 28 Apr 1998 21:10:09 +0200 Message-Id: <199804281910.VAA24910@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: daniele@zk3.dec.com CC: agentx@peer.com In-reply-to: <9804281307.AA32053@bernie.zk3.dec.com> (message from Mike Daniele on Tue, 28 Apr 98 09:07:05 -0400) Subject: Re: index allocation References: <9804281307.AA32053@bernie.zk3.dec.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII >>>>> Mike Daniele writes: Mike> My thinking was that v.name would never containing instance Mike> information, it would always be the oid prefix of an index Mike> object. That just seemed the simplest. Thanks Mike, this interpretation is fine with me. Anyway, this is something that should be clarified in a revision of the RFC. I have another question. Lets assume I have a fooTable indexed by two columns fooA and fooB. I want to allocate a single entry in the table. I would send an agentx-IndexAllocate-PDU with v.name1 = fooA, and v.name2 = fooB. The corresponding data elements contain the index values I would like to allocate. Is this correct? If yes, what happens if I want to allocate indexes for two rows in fooTable? Am I correct to send an agentx-IndexAllocate-PDU with v.name1 = fooA, v.name2 = fooB, v.name3 = fooA and v.name4 = fooB and appropriate data elements? What happens if the data elements v.data1 and v.data3 have the same value? I other words: How are complex index values grouped together? The text in section 7.1.2 looks like if each VarBind element is processed in isolation. 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 daniele@zk3.dec.com Wed Apr 29 10:22: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 KAA15332 for ; Wed, 29 Apr 1998 10:22:21 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA15920 for ; Wed, 29 Apr 1998 10:21:08 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma015889; Wed, 29 Apr 98 10:21:04 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id KAA20724 for ; Wed, 29 Apr 1998 10:20:41 -0500 (CDT) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma020262; Wed, 29 Apr 98 10:20:17 -0500 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 IAA24664 for ; Wed, 29 Apr 1998 08:10:28 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA13819 for ; Wed, 29 Apr 1998 10:10:26 -0500 (CDT) Received: from mail12.digital.com(192.208.46.20) by almond.bmc.com via smap (V2.0) id xma013772; Wed, 29 Apr 98 10:10:01 -0500 Received: from flume.zk3.dec.com (flume.zk3.dec.com [16.140.112.3]) by mail12.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id LAA05724; Wed, 29 Apr 1998 11:09:38 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA25494; Wed, 29 Apr 1998 11:09:31 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA00246; Wed, 29 Apr 1998 11:06:42 -0400 Message-Id: <9804291506.AA00246@bernie.zk3.dec.com> To: Juergen Schoenwaelder Cc: agentx@peer.com Subject: Re: index allocation In-Reply-To: Your message of "Tue, 28 Apr 98 21:10:09 +0200." <199804281910.VAA24910@henkell.ibr.cs.tu-bs.de> Date: Wed, 29 Apr 98 11:06:42 -0400 From: Mike Daniele X-Mts: smtp >Thanks Mike, this interpretation is fine with me. Anyway, this is >something that should be clarified in a revision of the RFC. Agreed. Bob, Dale, are we keeping a list of suggested revisions? >I have another question. Lets assume I have a fooTable indexed by two >columns fooA and fooB. I want to allocate a single entry in the >table. I would send an agentx-IndexAllocate-PDU with v.name1 = fooA, >and v.name2 = fooB. The corresponding data elements contain the index >values I would like to allocate. Is this correct? Yes, as described in the 4th paragraph of 7.1.3. >If yes, what happens if I want to allocate indexes for two rows in >fooTable? Am I correct to send an agentx-IndexAllocate-PDU with >v.name1 = fooA, v.name2 = fooB, v.name3 = fooA and v.name4 = fooB and >appropriate data elements? You could certainly do so if you wished. Or you could send multiple agentx-IndexAllocate-PDUs, each containing fewer varbinds. If you were requesting specific indexes be allocated, yes you'd place those values in the appropriate v.data elements. >What happens if the data elements v.data1 and v.data3 have the same value? Then one of them would fail, per step 4) (c) in 7.1.2. And per step 4), no index values would be allocated, and a response pdu indicating the error would be returned. >I other words: How are complex index values grouped together? The text >in section 7.1.2 looks like if each VarBind element is processed in >isolation. They are, to the extent that each varbind contains a wholly defined request for an index allocation, that can be processed individually. (One way to think of it is that the master agent maintains a database keyed by v.name values.) They are not, to the extent that if multiple varbinds are present in the PDU, their index allocations either all succeed, or none succeed. I hope I understood your question. I don't understand why a subagent would send multiple varbinds requesting exactly the same index allocation (same v.name, same v.data, both NEW_INDEX and ANY_INDEX bits clear) when the request can't possibly succeed... Regards, Mike From schoenw@ibr.cs.tu-bs.de Wed Apr 29 11:43: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 LAA16375 for ; Wed, 29 Apr 1998 11:43:25 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA22082 for ; Wed, 29 Apr 1998 11:42:12 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma021926; Wed, 29 Apr 98 11:41:46 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA13483 for ; Wed, 29 Apr 1998 11:41:23 -0500 (CDT) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma013285; Wed, 29 Apr 98 11:41:14 -0500 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 JAA28058 for ; Wed, 29 Apr 1998 09:33:28 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id LAA25545 for ; Wed, 29 Apr 1998 11:33:24 -0500 (CDT) Received: from ra.ibr.cs.tu-bs.de(134.169.34.12) by cashew.bmc.com via smap (V2.0) id xma025523; Wed, 29 Apr 98 11:32:52 -0500 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 SAA26508; Wed, 29 Apr 1998 18:32:50 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id SAA02782; Wed, 29 Apr 1998 18:32:48 +0200 Date: Wed, 29 Apr 1998 18:32:48 +0200 Message-Id: <199804291632.SAA02782@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: daniele@zk3.dec.com CC: agentx@peer.com In-reply-to: <9804291506.AA00246@bernie.zk3.dec.com> (message from Mike Daniele on Wed, 29 Apr 98 11:06:42 -0400) Subject: Re: index allocation References: <9804291506.AA00246@bernie.zk3.dec.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII >>>>> Mike Daniele writes: Thanks for your response. We are obviously in agreement about how index allocation works in RFC 2257. ;-) Mike> I hope I understood your question. I don't understand why a Mike> subagent would send multiple varbinds requesting exactly the Mike> same index allocation (same v.name, same v.data, both NEW_INDEX Mike> and ANY_INDEX bits clear) when the request can't possibly Mike> succeed... Let me explain why I asked this question: In my fooTable, the index for a particular row is the tuple (fooA, fooB). Lets assume I want to allocate indexes for single rows. I first allocate row 1 indexed by (1,1) and later row 2 indexed by (1,2). The second allocation will fail in AgentX because AgentX does only allocate index values per column name and the value 1 for column fooA is already allocated. It is therefore not possible to allocate row 1 (1,1) in subagent 1 and later allocate row 2 (1,2) in subagent 2, although the index values (1,1) and (1,2) for the two rows are fine. Now, the question is how much of a problem this is. I know of at least one IETF MIB that could have a problem with this AgentX behaviour: The application MIB has a notion of a service oriented view, which may span several instrumented processes. Processes are expected to export management information (e.g. some of the open channels for a given service) via their build-in AgentX subagents. Allocating entries in the application MIB tables that are indexes by service ID will only work if subagents do not allocate the service ID. A subagent which simply allocates all index elements for a row will allocate the service ID and lock out all other subagents for the given service. This is not a fatal problem as far as I understand it now because the application MIB should be implementable with AgentX if the subagents behave nicely. However, there might be other MIBs where this AgentX limitation might be even more serious. I just wanted to bring this issue up here so that we all know about it and can decide whether any action is necessary or if this is one of the limitations we accept for AgentX 1.0. If we accept this limitation, we should probably add some text in section 7.1.3 which talks about this issue and that a well-behaved subagent should only allocate those index elements that are "essential" and not necessarily all index elements of a given row. 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 daniele@zk3.dec.com Wed Apr 29 12:20: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 MAA16852 for ; Wed, 29 Apr 1998 12:20:16 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA26020 for ; Wed, 29 Apr 1998 12:19:03 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma025760; Wed, 29 Apr 98 12:18:01 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA20899 for ; Wed, 29 Apr 1998 12:17:37 -0500 (CDT) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma020399; Wed, 29 Apr 98 12:17:03 -0500 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 KAA29071 for ; Wed, 29 Apr 1998 10:08:06 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id MAA27743 for ; Wed, 29 Apr 1998 12:08:03 -0500 (CDT) Received: from mail13.digital.com(192.208.46.30) by cashew.bmc.com via smap (V2.0) id xma027736; Wed, 29 Apr 98 12:07:53 -0500 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.0d) with SMTP id NAA08288; Wed, 29 Apr 1998 13:07:48 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA02998; Wed, 29 Apr 1998 13:07:44 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA00994; Wed, 29 Apr 1998 13:05:26 -0400 Message-Id: <9804291705.AA00994@bernie.zk3.dec.com> To: Juergen Schoenwaelder Cc: agentx@peer.com Subject: Re: index allocation In-Reply-To: Your message of "Wed, 29 Apr 98 18:32:48 +0200." <199804291632.SAA02782@henkell.ibr.cs.tu-bs.de> Date: Wed, 29 Apr 98 13:05:26 -0400 From: Mike Daniele X-Mts: smtp Juergen wrote: >It is therefore not possible to allocate row 1 (1,1) in subagent 1 and >later allocate row 2 (1,2) in subagent 2, although the index values >(1,1) and (1,2) for the two rows are fine. That's correct. >Now, the question is how much of a problem this is. I know of at least >one IETF MIB that could have a problem with this AgentX behaviour: > >The application MIB has a notion of a service oriented view, which may >span several instrumented processes. Processes are expected to export >management information (e.g. some of the open channels for a given >service) via their build-in AgentX subagents. Allocating entries in >the application MIB tables that are indexes by service ID will only >work if subagents do not allocate the service ID. A subagent which >simply allocates all index elements for a row will allocate the >service ID and lock out all other subagents for the given service. Yup. >This is not a fatal problem as far as I understand it now because the >application MIB should be implementable with AgentX if the subagents >behave nicely. However, there might be other MIBs where this AgentX >limitation might be even more serious. I just want to note that if one assumes the instrumented processes all know their service ID, there is no need for them to allocate an index for it. They should allocate values for their second index, since they are apparently arbitrary. And then all registrations would work, which is the goal. I assume this is what you have in mind by "behave nicely"? >I just wanted to bring this issue up here so that we all know about it >and can decide whether any action is necessary or if this is one of >the limitations we accept for AgentX 1.0. If we accept this >limitation, we should probably add some text in section 7.1.3 which >talks about this issue and that a well-behaved subagent should only >allocate those index elements that are "essential" and not necessarily >all index elements of a given row. > Juergen Thanks for bringing it up. I don't recall this being raised as an issue earlier. I think you're right that including a clarifying example like this would help. Mike From rpresuhn@dorothy.peer.com Wed Apr 29 12:22:23 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 MAA16901 for ; Wed, 29 Apr 1998 12:22:22 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA26335 for ; Wed, 29 Apr 1998 12:21:10 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma026318; Wed, 29 Apr 98 12:20:52 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA23421 for ; Wed, 29 Apr 1998 12:20:29 -0500 (CDT) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma022957; Wed, 29 Apr 98 12:20:04 -0500 Received: (from rpresuhn@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id KAA29118 for agentx@peer.com; Wed, 29 Apr 1998 10:12:05 -0700 (PDT) Date: Wed, 29 Apr 1998 10:12:05 -0700 (PDT) From: Randy Presuhn Message-Id: <199804291712.KAA29118@dorothy.peer.com> To: agentx@peer.com Subject: Re: index allocation Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > Date: Wed, 29 Apr 1998 18:32:48 +0200 > From: Juergen Schoenwaelder > To: daniele@zk3.dec.com > CC: agentx@peer.com > Subject: Re: index allocation > References: <9804291506.AA00246@bernie.zk3.dec.com> ... > I just wanted to bring this issue up here so that we all know about it > and can decide whether any action is necessary or if this is one of > the limitations we accept for AgentX 1.0. If we accept this > limitation, we should probably add some text in section 7.1.3 which > talks about this issue and that a well-behaved subagent should only > allocate those index elements that are "essential" and not necessarily > all index elements of a given row. ... Although the historical discussions of index reservation (back as far as September, 1996) have treated the varbinds as unrelated, perhaps it might be worth going through the thought-exercise of considering what the implications would be of treating them as tuples. ----------------------------------------------------------------------- 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 Wed Apr 29 12:45: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 MAA17252 for ; Wed, 29 Apr 1998 12:45:31 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA28468 for ; Wed, 29 Apr 1998 12:44:18 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma028408; Wed, 29 Apr 98 12:43:55 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA18262 for ; Wed, 29 Apr 1998 12:43:31 -0500 (CDT) Received: from dorothy.peer.com(192.146.153.65) by dresden.bmc.com via smap (3.2) id xma017855; Wed, 29 Apr 98 12:43:10 -0500 Received: (from rpresuhn@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id KAA29381 for agentx@peer.com; Wed, 29 Apr 1998 10:35:23 -0700 (PDT) Date: Wed, 29 Apr 1998 10:35:23 -0700 (PDT) From: Randy Presuhn Message-Id: <199804291735.KAA29381@dorothy.peer.com> To: agentx@peer.com Subject: test - please ignore Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit (testing agentx@peer.com list) ----------------------------------------------------------------------- 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 root@dorothy.peer.com Wed Apr 29 13:29: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 NAA17861 for ; Wed, 29 Apr 1998 13:29:41 -0500 (CDT) From: root@dorothy.peer.com Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA01966 for ; Wed, 29 Apr 1998 13:28:28 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma001490; Wed, 29 Apr 98 13:27:02 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA04667 for ; Wed, 29 Apr 1998 13:26:39 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma003147; Wed, 29 Apr 98 13:25:31 -0500 Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id NAA19670; Wed, 29 Apr 1998 13:25:50 -0500 (CDT) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id LAA01049 for agentx@peer.com; Wed, 29 Apr 1998 11:20:02 -0700 (PDT) Date: Wed, 29 Apr 1998 11:20:02 -0700 (PDT) Message-Id: <199804291820.LAA01049@dorothy.peer.com> Subject: this is a test message, ignore it. test, ignore