From maria@xedia.com Wed Jul 1 04:14: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 EAA01272 for ; Wed, 1 Jul 1998 04:14:49 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id EAA01400 for ; Wed, 1 Jul 1998 04:14:40 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xmaa01398; Wed, 1 Jul 98 04:14:36 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id EAA06022 for ; Wed, 1 Jul 1998 04:14:04 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma005837; Wed, 1 Jul 98 04:13:42 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id EAA09993; Wed, 1 Jul 1998 04:14:13 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id CAA18032 for ; Wed, 1 Jul 1998 02:14:11 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id EAA01385 for ; Wed, 1 Jul 1998 04:14:10 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma001370; Wed, 1 Jul 98 04:13:41 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom (8.8.5/8.7.3) with ESMTP id EAA07734 for ; Wed, 1 Jul 1998 04:41:44 -0400 (EDT) Received: from ra.ibr.cs.tu-bs.de (ra.ibr.cs.tu-bs.de [134.169.34.12]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id EAA04378 for ; Wed, 1 Jul 1998 04:41:41 -0400 (EDT) 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 KAA09603; Wed, 1 Jul 1998 10:41:33 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id KAA05692; Wed, 1 Jul 1998 10:41:32 +0200 Date: Wed, 1 Jul 1998 10:41:32 +0200 Message-Id: <199807010841.KAA05692@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: rpresuhn@dorothy.bmc.com CC: disman@nexen.com In-reply-to: <199807010019.RAA02128@dorothy.bmc.com> (message from Randy Presuhn on Tue, 30 Jun 1998 17:19:12 -0700 (PDT)) Subject: Re: draft-ietf-disman-script-mib-04.txt References: <199807010019.RAA02128@dorothy.bmc.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII >>>>> Randy Presuhn writes: Randy> Everyone: here's your almost last call: please review this and Randy> the schedule MIBs carefully and bring any issues out on the Randy> list. Our target is to issue a working group last call Randy> shortly. Randy> When you post issues, it'd be nice if you could accompany that Randy> posting with a proposed solution or a statement as to whether Randy> the problem needs to be solved now or could perhaps be better Randy> addressed after we've gained more experience in the use of Randy> these MIBs. Here are two things we already know and which will be fixed in the final revision of the IDs. 1) The example in the Scheduling MIB draft refers to the Script MIB. Some of the instance identifier values are incorrect because we did the Scheduling MIB before we had the Script MIB ready. 2) The Script MIB needs an example which shows a `typical' script configuration and (more important) how VACM can be configured to protect the system. (I plan to post the example on this list first so that we do not have to wait until the final IDs are in place.) Also, I recently learned that using IMPLIED is pretty inconvenient if a table with an IMPLIED index needs to be expanded. For example, if we later want to add a table which logs the last N activations of a scheduling entry, then this table would be indexed by something like { schedOwner, schedName, lastNIndex }, which means that you can't use the instance identifier of the current schedTable directly in order to walk the relevant part of the last N activations table. I am not argueing that the example make much sense or that we foresee a need to expand the schedTable. But making expansions possible and easy to do seems a good reason for me to not use the IMPLIED keyword. And this is probably a general strong argument against the usage of IMPLIED. 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 maria@xedia.com Wed Jul 1 10:00: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 KAA05185 for ; Wed, 1 Jul 1998 10:00:35 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA17586 for ; Wed, 1 Jul 1998 10:00:24 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma017445; Wed, 1 Jul 98 09:59:40 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id JAA25124 for ; Wed, 1 Jul 1998 09:59:05 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma024880; Wed, 1 Jul 98 09:58:54 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id JAA27990; Wed, 1 Jul 1998 09:59:24 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA27666 for ; Wed, 1 Jul 1998 07:59:23 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id JAA17315 for ; Wed, 1 Jul 1998 09:59:21 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma017231; Wed, 1 Jul 98 09:58:44 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom (8.8.5/8.7.3) with ESMTP id KAA15206 for ; Wed, 1 Jul 1998 10:28:43 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id KAA05387 for ; Wed, 1 Jul 1998 10:28:42 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA09147; Wed, 1 Jul 1998 10:28:37 -0400 (EDT) Message-Id: <199807011428.KAA09147@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@nexen.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-disman-script-mib-04.txt Date: Wed, 01 Jul 1998 10:28:37 -0400 Sender: cclark@ns.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 Distributed Management Working Group of the IETF. Title : Definitions of Managed Objects for the Delegation of Management Scripts Author(s) : D. Levi, J. Schoenwaelder Filename : draft-ietf-disman-script-mib-04.txt Pages : 62 Date : 30-Jun-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 a set of managed objects that allow the delegation of management scripts to distributed managers. 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-disman-script-mib-04.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-disman-script-mib-04.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-disman-script-mib-04.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: <19980630151835.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-script-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-script-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980630151835.I-D@ietf.org> --OtherAccess-- --NextPart-- From maria@xedia.com Wed Jul 1 12:43: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 MAA07041 for ; Wed, 1 Jul 1998 12:43:51 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA28241 for ; Wed, 1 Jul 1998 12:43:42 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma028236; Wed, 1 Jul 98 12:43:25 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA27481 for ; Wed, 1 Jul 1998 12:42:52 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma027403; Wed, 1 Jul 98 12:42:48 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id MAA12728; Wed, 1 Jul 1998 12:43:13 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA02489 for ; Wed, 1 Jul 1998 10:43:06 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id MAA13253 for ; Wed, 1 Jul 1998 12:43:04 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma013246; Wed, 1 Jul 98 12:42:44 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom (8.8.5/8.7.3) with ESMTP id MAA20196 for ; Wed, 1 Jul 1998 12:49:33 -0400 (EDT) Received: from des.castles.com (des.castles.com [208.214.166.35]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id MAA06211 for ; Wed, 1 Jul 1998 12:49:31 -0400 (EDT) Received: (from hardaker@localhost) by des.castles.com (8.8.7/8.8.7) id JAA12332; Wed, 1 Jul 1998 09:49:16 -0700 Sender: hardaker@des.castles.com To: disman@nexen.com Subject: disman status and target-mib X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 X-url: http://dcas.ucdavis.edu/~hardaker Organization: U.C.Davis, Information Technology - D.C.A.S. Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Wes Hardaker Date: 01 Jul 1998 09:41:58 -0700 Message-ID: X-Mailer: Gnus v5.6.10/XEmacs 20.4 - "Emerald" Lines: 14 1) What's the status of the disman work at this point? I haven't been following the list long enough to determine how stable the MIBs are so far. Specifically, I'm considering implementing some of the DISMAN mibs (the notification and event mibs, to be more specific) and wanted to know how stable they were at this point. Have other implementations begun yet? 2) The target-mib has expired, so I haven't been able to get a copy of it, which is where I'd have to start (since the above mibs depend on this one)... -- "Ninjas aren't dangerous. They're more afraid of you than you are of them." From maria@xedia.com Wed Jul 1 16:31:50 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 QAA09635 for ; Wed, 1 Jul 1998 16:31:49 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA12098 for ; Wed, 1 Jul 1998 16:31:39 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma012085; Wed, 1 Jul 98 16:31:21 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA25531 for ; Wed, 1 Jul 1998 16:30:48 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma025101; Wed, 1 Jul 98 16:30:23 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA16128; Wed, 1 Jul 1998 16:30:49 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA20379 for ; Wed, 1 Jul 1998 14:30:47 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id QAA24147 for ; Wed, 1 Jul 1998 16:30:45 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma024091; Wed, 1 Jul 98 16:30:10 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom (8.8.5/8.7.3) with ESMTP id RAA28273 for ; Wed, 1 Jul 1998 17:10:29 -0400 (EDT) Received: from rumor.research.att.com (rumor.research.att.com [192.20.225.9]) by guelah.nexen.com (8.8.5/8.7.3) with SMTP id RAA07407 for ; Wed, 1 Jul 1998 17:10:28 -0400 (EDT) Received: from research.att.com ([135.207.30.100]) by rumor; Wed Jul 1 17:04:42 EDT 1998 Received: from corona.research.att.com ([135.207.26.21]) by research; Wed Jul 1 17:07:14 EDT 1998 Received: (from im99@localhost) by corona.research.att.com (8.8.7/8.8.7) id RAA14264 for disman@nexen.com; Wed, 1 Jul 1998 17:07:13 -0400 (EDT) Date: Wed, 1 Jul 1998 17:07:13 -0400 (EDT) From: IM99 conference Message-Id: <199807012107.RAA14264@corona.research.att.com> To: disman@nexen.com Subject: IM 99 submission deadline extended to July 15 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ _/ _/_/_/_/ _/_/_/_/ _/ _/_/ _/_/ _/ _/ _/ _/ _/ _/ _/ _/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/_/_/_/ _/_/_/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/_/_/ _/_/_/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ IFIP/IEEE INTERNATIONAL SYMPOSIUM ON INTEGRATED NETWORK MANAGEMENT _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Dear colleagues, Due to popular demand, we have extended the paper submission deadline to July 15th, 1998. Please make a note. --------------- See http://www.comsoc.org/confs/im/99 for call for papers Deadline for Receipt of Papers: July 15, 1998 Deadline for Receipt of Proposals for Tutorials, BOFs, Panels and Posters August 15, 1998 Notification of Acceptance Mailed: November 4, 1998 Final Camera Ready Papers Due: December 12, 1998 SUBMISSION INSTRUCTIONS The front page of the paper should contain author names and addresses, an abstract and keywords indicating the paper topic area (preferably from the above list), to be used in choosing referees. ELECTRONIC SUBMISSION IS ADVISABLE. Authors are requested to submit papers in PDF or postscript format via the web (instructions for electronic submissions are available at) http://nsm.research.bell-labs.com/~im99/SubmitPaper.html or by email to Subrata Mazumdar at mazum@research.bell-labs.com. For ALL electronic submissions the cover page of the paper should be submitted using the on-line form available at http://nsm.research.bell-labs.com/~im99/SubmitPaper.html and and a printed copy posted to the appropriate Program Co-Chair. Program Co-Chair: (Americas, Australia) Subrata Mazumdar Bell Laboratories Room 4G-634 101 Crawfords Corner Road Holmdel, New Jersey 07733-3030, USA Email: mazum@research.bell-labs.com OR Program Co-Chair: (Europe, Asia, Africa) Morris Sloman Department of Computing Imperial College of Science and Technology 180 Queen's Gate London SW7 2BZ, UK Email: mss@doc.ic.ac.uk Poster presentations should be submitted to either of the Program Co-Chairs. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From maria@xedia.com Wed Jul 1 16:36: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 QAA09699 for ; Wed, 1 Jul 1998 16:36:44 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA12571 for ; Wed, 1 Jul 1998 16:36:34 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma012558; Wed, 1 Jul 98 16:36:10 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA29835 for ; Wed, 1 Jul 1998 16:35:38 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma029359; Wed, 1 Jul 98 16:35:08 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA17525; Wed, 1 Jul 1998 16:35:39 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA20862 for ; Wed, 1 Jul 1998 14:35:33 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA12471 for ; Wed, 1 Jul 1998 16:35:31 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma012449; Wed, 1 Jul 98 16:35:06 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA28873 for ; Wed, 1 Jul 1998 16:34:33 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by dresden.bmc.com via smap (3.2) id xma028663; Wed, 1 Jul 98 16:34:20 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom (8.8.5/8.7.3) with ESMTP id RAA27890 for ; Wed, 1 Jul 1998 17:02:24 -0400 (EDT) Received: from ra.ibr.cs.tu-bs.de (ra.ibr.cs.tu-bs.de [134.169.34.12]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id RAA21959 for ; Wed, 1 Jul 1998 17:02:21 -0400 (EDT) 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 XAA26365; Wed, 1 Jul 1998 23:02:19 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id XAA17388; Wed, 1 Jul 1998 23:02:18 +0200 Date: Wed, 1 Jul 1998 23:02:18 +0200 Message-Id: <199807012102.XAA17388@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: wjhardaker@ucdavis.edu CC: disman@nexen.com In-reply-to: (message from Wes Hardaker on 01 Jul 1998 09:41:58 -0700) Subject: Re: disman status and target-mib References: Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII >>>>> Wes Hardaker writes: Wes> 1) What's the status of the disman work at this point? I haven't Wes> been following the list long enough to determine how stable the Wes> MIBs are so far. Specifically, I'm considering implementing some Wes> of the DISMAN mibs (the notification and event mibs, to be more Wes> specific) and wanted to know how stable they were at this point. Wes> Have other implementations begun yet? I am not able to talk about the notification and event mibs. Anyway, I hope that the scheduling and script mibs are pretty stable now. We plan to start WG last call on these mibs during this months. We are working on an implementation of the Script MIB which has helped quite a bit to clean up the MIB definitions. For more details about this implementation, visit http://www.ibr.cs.tu-bs.de/projects/jasmin/ or contact me directly. We did not yet implement the scheduling mib, but I do not see major problems with it as it is pretty simple compared to the script MIB. Wes> 2) The target-mib has expired, so I haven't been able to get a Wes> copy of it, which is where I'd have to start (since the above Wes> mibs depend on this one)... Is it possible that you are looking at old documents? The latest versions are: draft-ietf-disman-event-mib-03.txt (13 March 1998) draft-ietf-disman-notif-log-mib-02.txt (13 March 1998) These documents depend on the target and notification mibs defined in RFC 2273. (You probably want to implement them first.) 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 maria@xedia.com Fri Jul 3 09:18: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 JAA03782 for ; Fri, 3 Jul 1998 09:18:26 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id JAA29314 for ; Fri, 3 Jul 1998 09:18:14 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma029302; Fri, 3 Jul 98 09:17:54 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id JAA02103 for ; Fri, 3 Jul 1998 09:17:22 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma002075; Fri, 3 Jul 98 09:17:18 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id JAA01860; Fri, 3 Jul 1998 09:17:47 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA28283 for ; Fri, 3 Jul 1998 07:17:45 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id JAA29299 for ; Fri, 3 Jul 1998 09:17:44 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma029290; Fri, 3 Jul 98 09:17:30 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom (8.8.5/8.7.3) with ESMTP id JAA11042 for ; Fri, 3 Jul 1998 09:38:13 -0400 (EDT) Received: from ra.ibr.cs.tu-bs.de (ra.ibr.cs.tu-bs.de [134.169.34.12]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id JAA12611 for ; Fri, 3 Jul 1998 09:38:07 -0400 (EDT) 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 PAA09308; Fri, 3 Jul 1998 15:38:04 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id PAA12263; Fri, 3 Jul 1998 15:38:02 +0200 Date: Fri, 3 Jul 1998 15:38:02 +0200 Message-Id: <199807031338.PAA12263@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: disman@nexen.com, snmpv3@tis.com Subject: VACM and DISMAN Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII I am trying to find `good' VACM configurations for the Script MIB. And it turns out that this is more complex than I thought. What I would like to have for the Script MIB is what people usually call "role based access control" (RBAC): A user (a snmpSecurityName in RFC 2271 speak) maps to one of more roles he has (e.g. routing administrator, web service manager, data collector) and each role has associated "transactions" that can be called in order to fulfill the tasks for a given role. Transactions are either SNMP operations (in case of traditional agents) or more complex management functions implemented via scripts. It would be cool if VACM could be configured so that we get something pretty similar to the RBAC model described above. In an ideal world, the security administrator would configure VACM so that it is pretty easy to assign user "joe" the role of a "routing administrator and data collector" and user "lara" the role of a "web service manager and data collector". I started to look deeper into VACM and I finally realized that VACM is not ideal with regard to the RBAC model described above: 1) At first glance, it looks like if the VACM group can be used to describe roles. However, a given user (identified by securityName and securityModel) can only be in a single group, which makes it impossible to assign multiple "roles" to a user. This means that in the example above, I have to create a group "routing administrator and data collector" and another group "web service manager and data collector". An alternative would be to give the principals "joe" and "lara" two snmpSecurityNames and tell them that they are responsible to select the right name for a given task. 2) Having to define lots of groups would not be that bad if one could at least share common view tree family definitions. However, VACM does not allow to do that. So, in the example, I would have to duplicate the tree family entries needed to be a data collector for the groups "routing administrator and data collector" and "web service manager and data collector", which does not look very attractive. Things get really worse if you have a DISMAN environment and you want to give users their own "sandboxes" where they can install scripts of expressions to be evalutated. You either end up doing a one-to-one mapping between securityNames and VACM groups (thus rendering VACM groups useless and duplicating entries in the tree family table) or you hand out another securityName which is used to select the private "sandbox". Please let me know if I have just overlooked something in RFC 2275. If my interpretation of RFC 2275 is correct, I would argue that VACM might work pretty well to protect small agents without many control objects. But VACM has a pretty serious scalability problems for agents where you need different but similar levels of access control of multiple users, like the Script MIB. Are there already fielded implementations of VACM? Are there any experiences or guidelines how to use it without creating huge MIB tables? 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 maria@xedia.com Fri Jul 3 13:52: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 NAA05864 for ; Fri, 3 Jul 1998 13:52:47 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA09058 for ; Fri, 3 Jul 1998 13:52:33 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma009048; Fri, 3 Jul 98 13:52:22 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA16996 for ; Fri, 3 Jul 1998 13:51:50 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma016981; Fri, 3 Jul 98 13:51:48 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id NAA17449; Fri, 3 Jul 1998 13:52:18 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA06030 for ; Fri, 3 Jul 1998 11:52:17 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id NAA04969 for ; Fri, 3 Jul 1998 13:52:15 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma004961; Fri, 3 Jul 98 13:51:45 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom (8.8.5/8.7.3) with ESMTP id OAA14635 for ; Fri, 3 Jul 1998 14:22:34 -0400 (EDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id OAA12878 for ; Fri, 3 Jul 1998 14:22:33 -0400 (EDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id OAA09960; Fri, 3 Jul 1998 14:22:22 -0400 Received: from watpub1.watson.ibm.com (watpub1.watson.ibm.com [9.2.101.12]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id OAA15952; Fri, 3 Jul 1998 14:22:21 -0400 Received: by watpub1.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA30164; Fri, 3 Jul 1998 14:22:17 -0400 From: Uri Blumenthal Message-Id: <9807031822.AA30164@watpub1.watson.ibm.com> Subject: Re: VACM and DISMAN To: schoenw@ibr.cs.tu-bs.de (Juergen Schoenwaelder) Date: Fri, 3 Jul 1998 14:22:16 -0400 (EDT) Cc: disman@nexen.com, snmpv3@tis.com In-Reply-To: <199807031338.PAA12263@henkell.ibr.cs.tu-bs.de> from "Juergen Schoenwaelder" at Jul 3, 98 03:38:02 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Juergen Schoenwaelder says: > I am trying to find `good' VACM configurations for the Script MIB. And > it turns out that this is more complex than I thought. What I would > like to have for the Script MIB is what people usually call "role > based access control" (RBAC): IMHO, VACM was not designed to accomodate it. One *can* use it that way by modifying the "match" criteria. > I started to look deeper into VACM and I finally realized that VACM is > not ideal with regard to the RBAC model described above: > > 1) At first glance, it looks like if the VACM group can be used to > describe roles. However, a given user (identified by securityName > and securityModel) can only be in a single group, which makes it > impossible to assign multiple "roles" to a user. If a principal can be a member of more than one group, the main obstacle is how to choose which group to use for access control decisions? > This means that in > the example above, I have to create a group "routing administrator > and data collector" and another group "web service manager and data > collector". Whch is no big deal, except how would you convey which group to use? > An alternative would be to give the principals "joe" > and "lara" two snmpSecurityNames and tell them that they are > responsible to select the right name for a given task. It works now, but it is ugly. > Please let me know if I have just overlooked something in RFC 2275. If > my interpretation of RFC 2275 is correct, I would argue that VACM > might work pretty well to protect small agents without many control > objects. Partially disagree. VACM was to protect small agents with limited resources, but not necessarily few control objects... What is needed is some way to deal with one-principal-in-many-groups issue. Do you add a group or a role to the PDU? Do you modify the matching algorithm (if so - how)? -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From maria@xedia.com Sat Jul 4 13:39: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 NAA00400 for ; Sat, 4 Jul 1998 13:39:29 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA02059 for ; Sat, 4 Jul 1998 13:39:14 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma002057; Sat, 4 Jul 98 13:38:52 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA11834 for ; Sat, 4 Jul 1998 13:38:19 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma011771; Sat, 4 Jul 98 13:37:54 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id NAA19436; Sat, 4 Jul 1998 13:38:19 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA15717 for ; Sat, 4 Jul 1998 11:38:15 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA02050 for ; Sat, 4 Jul 1998 13:38:14 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma002048; Sat, 4 Jul 98 13:37:44 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom (8.8.5/8.7.3) with ESMTP id NAA01198 for ; Sat, 4 Jul 1998 13:56:51 -0400 (EDT) Received: from ra.ibr.cs.tu-bs.de (ra.ibr.cs.tu-bs.de [134.169.34.12]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id NAA12216 for ; Sat, 4 Jul 1998 13:56:49 -0400 (EDT) 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 TAA22372; Sat, 4 Jul 1998 19:56:47 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id TAA23362; Sat, 4 Jul 1998 19:56:42 +0200 Date: Sat, 4 Jul 1998 19:56:42 +0200 Message-Id: <199807041756.TAA23362@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: uri@watson.ibm.com CC: disman@nexen.com, snmpv3@tis.com In-reply-to: <9807031822.AA30164@watpub1.watson.ibm.com> (message from Uri Blumenthal on Fri, 3 Jul 1998 14:22:16 -0400 (EDT)) Subject: Re: VACM and DISMAN References: <9807031822.AA30164@watpub1.watson.ibm.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII >>>>> Uri Blumenthal writes: >> I started to look deeper into VACM and I finally realized that VACM >> is not ideal with regard to the RBAC model described above: >> >> 1) At first glance, it looks like if the VACM group can be used to >> describe roles. However, a given user (identified by securityName >> and securityModel) can only be in a single group, which makes it >> impossible to assign multiple "roles" to a user. Uri> If a principal can be a member of more than one group, the main Uri> obstacle is how to choose which group to use for access control Uri> decisions? Depends on the semantics you use. For DISMAN, something similar to the UNIX model would be suitable where the access rigths are actually the union of the access rights for each group. You simply loop over all the groups for a given pair and you return "access allowed" as soon as you got a positive match. If the loop completes without a match, you return "access denied". This is only an example. You can define more complicated functions. It is all a matter of what the semantics should be of being in multiple groups. >> This means that in the example above, I have to create a group >> "routing administrator and data collector" and another group "web >> service manager and data collector". Uri> Whch is no big deal, except how would you convey which group to Uri> use? You are right that a strict RBAC model would need to convey the role. I am not saying that we have to have a strict RBAC model. I am saying that a reasonable and scalable VACM configuration for the DISMAN Script MIB does not seem to be possible without creating several snmpSecurityNames for a user and lots of repeated entries in the view family tables. Sure, VACM can be modified to solve that problem. The SNMPv3 WG has to decide what to do. But you can be sure that I will be back when people want to gather operational experiences. 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 maria@xedia.com Sun Jul 5 18:15: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 SAA00955 for ; Sun, 5 Jul 1998 18:15:35 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id SAA09456 for ; Sun, 5 Jul 1998 18:15:16 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma009454; Sun, 5 Jul 98 18:15:16 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id SAA13225 for ; Sun, 5 Jul 1998 18:14:43 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma013124; Sun, 5 Jul 98 18:14:21 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id SAA22401; Sun, 5 Jul 1998 18:14:50 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id QAA03254 for ; Sun, 5 Jul 1998 16:14:47 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id SAA09451 for ; Sun, 5 Jul 1998 18:14:46 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma009449; Sun, 5 Jul 98 18:14:40 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom (8.8.5/8.7.3) with ESMTP id SAA21239 for ; Sun, 5 Jul 1998 18:35:31 -0400 (EDT) Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.192.161]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id SAA15522 for ; Sun, 5 Jul 1998 18:35:30 -0400 (EDT) Received: (kzm@localhost) by foxhound.cisco.com (8.8.4-Cisco.1/8.6.5) id PAA22692; Sun, 5 Jul 1998 15:34:15 -0700 (PDT) From: Keith McCloghrie Message-Id: <199807052234.PAA22692@foxhound.cisco.com> Subject: Re: VACM and DISMAN To: schoenw@ibr.cs.tu-bs.de (Juergen Schoenwaelder) Date: Sun, 5 Jul 1998 15:34:15 -0700 (PDT) Cc: uri@watson.ibm.com, disman@nexen.com, snmpv3@tis.com In-Reply-To: <199807041756.TAA23362@henkell.ibr.cs.tu-bs.de> from "Juergen Schoenwaelder" at Jul 4, 98 07:56:42 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > >> I started to look deeper into VACM and I finally realized that VACM > >> is not ideal with regard to the RBAC model described above: > >> > >> 1) At first glance, it looks like if the VACM group can be used to > >> describe roles. However, a given user (identified by securityName > >> and securityModel) can only be in a single group, which makes it > >> impossible to assign multiple "roles" to a user. > > Uri> If a principal can be a member of more than one group, the main > Uri> obstacle is how to choose which group to use for access control > Uri> decisions? > > Depends on the semantics you use. For DISMAN, something similar to the > UNIX model would be suitable where the access rigths are actually the > union of the access rights for each group. You simply loop over all > the groups for a given pair and you > return "access allowed" as soon as you got a positive match. If the > loop completes without a match, you return "access denied". This loop will have a performance impact. It's already the case that a GetNext can take a significant amount of processing due to access-control checking; your loop has a multiplicative effect on that. An implementation could pre-compute the tree for each user, but that could require a significant amount of memory. > This is only an example. You can define more complicated functions. > It is all a matter of what the semantics should be of being in > multiple groups. I understand it was only an example. Hopefully, there's another example which has a lesser performance impact. Keith. From maria@xedia.com Mon Jul 6 03:57:50 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 DAA01193 for ; Mon, 6 Jul 1998 03:57:50 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id DAA13705 for ; Mon, 6 Jul 1998 03:57:31 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma013703; Mon, 6 Jul 98 03:57:06 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id DAA21189 for ; Mon, 6 Jul 1998 03:56:33 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma021136; Mon, 6 Jul 98 03:56:17 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id DAA21723; Mon, 6 Jul 1998 03:56:47 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id BAA19269 for ; Mon, 6 Jul 1998 01:56:45 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id DAA15470 for ; Mon, 6 Jul 1998 03:56:43 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma015465; Mon, 6 Jul 98 03:56:27 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom (8.8.5/8.7.3) with ESMTP id EAA28576 for ; Mon, 6 Jul 1998 04:33:54 -0400 (EDT) Received: from ra.ibr.cs.tu-bs.de (ra.ibr.cs.tu-bs.de [134.169.34.12]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id EAA00750 for ; Mon, 6 Jul 1998 04:33:52 -0400 (EDT) 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 KAA03446; Mon, 6 Jul 1998 10:33:40 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id KAA10366; Mon, 6 Jul 1998 10:33:40 +0200 Date: Mon, 6 Jul 1998 10:33:40 +0200 Message-Id: <199807060833.KAA10366@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: kzm@cisco.com CC: disman@nexen.com, snmpv3@tis.com In-reply-to: <199807052234.PAA22692@foxhound.cisco.com> (message from Keith McCloghrie on Sun, 5 Jul 1998 15:34:15 -0700 (PDT)) Subject: Re: VACM and DISMAN References: <199807052234.PAA22692@foxhound.cisco.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII >>>>> Keith McCloghrie writes: Keith> This loop will have a performance impact. It's already the Keith> case that a GetNext can take a significant amount of processing Keith> due to access-control checking; your loop has a multiplicative Keith> effect on that. An implementation could pre-compute the tree Keith> for each user, but that could require a significant amount of Keith> memory. I disaggree that allowiong a user to be a member in multiple groups has a multiplicative effect on the getnext/getbulk performance. VACM currently requires the security administrator to configure the pre-computed trees for all group combinations. This means lots of VACM tree family entries while the time to do access control checking (which is essentially the number of discarded getnexts/getbulks) will be roughly the same. The performance penalty is a function of the access control rules in place. It is IMHO only marginally influenced by the scheme you use to describe the access control rules. 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 maria@xedia.com Mon Jul 6 03:58:22 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 DAA01197 for ; Mon, 6 Jul 1998 03:58:22 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id DAA13732 for ; Mon, 6 Jul 1998 03:58:02 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma013711; Mon, 6 Jul 98 03:57:36 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id DAA21298 for ; Mon, 6 Jul 1998 03:57:03 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma021197; Mon, 6 Jul 98 03:56:35 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id DAA21801; Mon, 6 Jul 1998 03:57:04 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id BAA19286 for ; Mon, 6 Jul 1998 01:57:01 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id DAA13700 for ; Mon, 6 Jul 1998 03:57:00 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma013698; Mon, 6 Jul 98 03:56:45 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom (8.8.5/8.7.3) with ESMTP id EAA28548 for ; Mon, 6 Jul 1998 04:29:10 -0400 (EDT) Received: from jyracomms.jyra.com (mail.jyra.com [193.117.248.2]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id EAA18182 for ; Mon, 6 Jul 1998 04:29:05 -0400 (EDT) Received: from jyrapete (192.168.42.72) by jyracomms.jyra.com (Worldmail 1.3.167); 6 Jul 1998 09:28:18 +0100 Received: by localhost with Microsoft MAPI; Mon, 6 Jul 1998 09:28:32 +0100 Message-ID: <01BDA8C0.7140C7E0.pete@jyra.com> From: Pete Lynch To: "'Juergen Schoenwaelder'" , "disman@nexen.com" , "snmpv3@tis.com" Subject: RE: VACM and DISMAN Date: Mon, 6 Jul 1998 09:28:29 +0100 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Can't the user/group identity stuff be done at the client: - leave VACM as it is. Have your client establish one user ID for each user or group - maintain the membership records at the client - try to access view under user id alone - try to access view under each group id in turn - cache "best" result for remainder of "management session" or until you feel the world may have changed That achieves the end result for the time being without changing SNMPv3. The user/group mapping may be done completely independently (for example, in an LDAP directory), reducing the complexity of security administration. That said, given that the performance penalty only really exists when a user is a member of many groups, and is thus capable of being worked around. I would be comfortable with changing the spec. Pete -----Original Message----- From: Juergen Schoenwaelder [SMTP:schoenw@ibr.cs.tu-bs.de] Sent: Friday, July 03, 1998 14:38 To: disman@nexen.com; snmpv3@tis.com Subject: VACM and DISMAN I am trying to find `good' VACM configurations for the Script MIB. And it turns out that this is more complex than I thought. What I would like to have for the Script MIB is what people usually call "role based access control" (RBAC): A user (a snmpSecurityName in RFC 2271 speak) maps to one of more roles he has (e.g. routing administrator, web service manager, data collector) and each role has associated "transactions" that can be called in order to fulfill the tasks for a given role. Transactions are either SNMP operations (in case of traditional agents) or more complex management functions implemented via scripts. It would be cool if VACM could be configured so that we get something pretty similar to the RBAC model described above. In an ideal world, the security administrator would configure VACM so that it is pretty easy to assign user "joe" the role of a "routing administrator and data collector" and user "lara" the role of a "web service manager and data collector". I started to look deeper into VACM and I finally realized that VACM is not ideal with regard to the RBAC model described above: 1) At first glance, it looks like if the VACM group can be used to describe roles. However, a given user (identified by securityName and securityModel) can only be in a single group, which makes it impossible to assign multiple "roles" to a user. This means that in the example above, I have to create a group "routing administrator and data collector" and another group "web service manager and data collector". An alternative would be to give the principals "joe" and "lara" two snmpSecurityNames and tell them that they are responsible to select the right name for a given task. 2) Having to define lots of groups would not be that bad if one could at least share common view tree family definitions. However, VACM does not allow to do that. So, in the example, I would have to duplicate the tree family entries needed to be a data collector for the groups "routing administrator and data collector" and "web service manager and data collector", which does not look very attractive. Things get really worse if you have a DISMAN environment and you want to give users their own "sandboxes" where they can install scripts of expressions to be evalutated. You either end up doing a one-to-one mapping between securityNames and VACM groups (thus rendering VACM groups useless and duplicating entries in the tree family table) or you hand out another securityName which is used to select the private "sandbox". Please let me know if I have just overlooked something in RFC 2275. If my interpretation of RFC 2275 is correct, I would argue that VACM might work pretty well to protect small agents without many control objects. But VACM has a pretty serious scalability problems for agents where you need different but similar levels of access control of multiple users, like the Script MIB. Are there already fielded implementations of VACM? Are there any experiences or guidelines how to use it without creating huge MIB tables? 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 maria@xedia.com Mon Jul 6 10:50: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 KAA01300 for ; Mon, 6 Jul 1998 10:50:38 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA25220 for ; Mon, 6 Jul 1998 10:50:18 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma025216; Mon, 6 Jul 98 10:50:11 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id KAA09142 for ; Mon, 6 Jul 1998 10:49:38 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma008553; Mon, 6 Jul 98 10:49:09 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id KAA21215; Mon, 6 Jul 1998 10:49:40 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA01079 for ; Mon, 6 Jul 1998 08:49:38 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id KAA27871 for ; Mon, 6 Jul 1998 10:49:36 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma027864; Mon, 6 Jul 98 10:49:24 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom (8.8.5/8.7.3) with ESMTP id LAA07001 for ; Mon, 6 Jul 1998 11:02:56 -0400 (EDT) Received: from des.castles.com (des.castles.com [208.214.166.35]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id LAA20264 for ; Mon, 6 Jul 1998 11:02:54 -0400 (EDT) Received: (from hardaker@localhost) by des.castles.com (8.8.7/8.8.7) id IAA08185; Mon, 6 Jul 1998 08:02:34 -0700 Sender: hardaker@des.castles.com To: Juergen Schoenwaelder Cc: wjhardaker@ucdavis.edu, disman@nexen.com Subject: Re: disman status and target-mib References: <199807012102.XAA17388@henkell.ibr.cs.tu-bs.de> X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 X-url: http://dcas.ucdavis.edu/~hardaker Organization: U.C.Davis, Information Technology - D.C.A.S. Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Wes Hardaker Date: 06 Jul 1998 07:57:01 -0700 In-Reply-To: Juergen Schoenwaelder's message of "Wed, 1 Jul 1998 23:02:18 +0200" Message-ID: X-Mailer: Gnus v5.6.10/XEmacs 20.4 - "Emerald" Lines: 13 >>>>> On Wed, 1 Jul 1998 23:02:18 +0200, Juergen Schoenwaelder said: Juergen> draft-ietf-disman-event-mib-03.txt (13 March 1998) Juergen> draft-ietf-disman-notif-log-mib-02.txt (13 March 1998) Juergen> These documents depend on the target and notification mibs Juergen> defined in RFC 2273. (You probably want to implement them Juergen> first.) Ahh... I wasn't aware they were RFC published yet. I'll go grab the RFC. -- "Ninjas aren't dangerous. They're more afraid of you than you are of them." From maria@xedia.com Mon Jul 6 12:51: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 MAA01333 for ; Mon, 6 Jul 1998 12:51:19 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA00062 for ; Mon, 6 Jul 1998 12:50:59 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma000059; Mon, 6 Jul 98 12:50:43 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA07094 for ; Mon, 6 Jul 1998 12:50:10 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma006905; Mon, 6 Jul 98 12:50:01 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id MAA23033; Mon, 6 Jul 1998 12:50:32 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA05637 for ; Mon, 6 Jul 1998 10:50:30 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA00051 for ; Mon, 6 Jul 1998 12:50:29 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma000048; Mon, 6 Jul 98 12:50:27 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom (8.8.5/8.7.3) with ESMTP id NAA11196 for ; Mon, 6 Jul 1998 13:19:03 -0400 (EDT) Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.192.161]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id NAA02267 for ; Mon, 6 Jul 1998 13:19:02 -0400 (EDT) Received: (kzm@localhost) by foxhound.cisco.com (8.8.4-Cisco.1/8.6.5) id KAA11219; Mon, 6 Jul 1998 10:18:00 -0700 (PDT) From: Keith McCloghrie Message-Id: <199807061718.KAA11219@foxhound.cisco.com> Subject: Re: VACM and DISMAN To: schoenw@ibr.cs.tu-bs.de (Juergen Schoenwaelder) Date: Mon, 6 Jul 1998 10:17:59 -0700 (PDT) Cc: kzm@cisco.com, disman@nexen.com, snmpv3@tis.com In-Reply-To: <199807060833.KAA10366@henkell.ibr.cs.tu-bs.de> from "Juergen Schoenwaelder" at Jul 6, 98 10:33:40 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > Keith> This loop will have a performance impact. It's already the > Keith> case that a GetNext can take a significant amount of processing > Keith> due to access-control checking; your loop has a multiplicative > Keith> effect on that. An implementation could pre-compute the tree > Keith> for each user, but that could require a significant amount of > Keith> memory. > > I disaggree that allowiong a user to be a member in multiple groups > has a multiplicative effect on the getnext/getbulk performance. As I understood your proposal, each iteration of the "loop" that you proposed was to test a particular group's access privileges, so that the number of times around the loop is the number of groups that a user is in, i.e., denying an access for a user in N groups is N times as much checking as denying a user in one group. That's what I meant by multiplicative. This is independent of GetNext/GetBulk. However, N times a larger number is a larger absolute/more noticeable increase, and so it's GetNext performance which appears to suffer most. Did I misunderstand ? > VACM currently requires the security administrator to configure the > pre-computed trees for all group combinations. This means lots of VACM > tree family entries while the time to do access control checking > (which is essentially the number of discarded getnexts/getbulks) will > be roughly the same. > > The performance penalty is a function of the access control rules in > place. It is IMHO only marginally influenced by the scheme you use to > describe the access control rules. Right, putting users in multiple groups has performance implications, which is the point I was trying to make in my original message. Keith. From maria@xedia.com Mon Jul 6 13:35:20 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 NAA01346 for ; Mon, 6 Jul 1998 13:35:19 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA01585 for ; Mon, 6 Jul 1998 13:34:59 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma001566; Mon, 6 Jul 98 13:34:38 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA24114 for ; Mon, 6 Jul 1998 13:34:05 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma023534; Mon, 6 Jul 98 13:33:31 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id NAA04227; Mon, 6 Jul 1998 13:34:02 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA06837 for ; Mon, 6 Jul 1998 11:33:57 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id NAA05687 for ; Mon, 6 Jul 1998 13:33:55 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma005677; Mon, 6 Jul 98 13:33:52 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom (8.8.5/8.7.3) with ESMTP id OAA12926 for ; Mon, 6 Jul 1998 14:03:50 -0400 (EDT) Received: from ra.ibr.cs.tu-bs.de (ra.ibr.cs.tu-bs.de [134.169.34.12]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id OAA21609 for ; Mon, 6 Jul 1998 14:03:49 -0400 (EDT) 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 UAA21615; Mon, 6 Jul 1998 20:03:47 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id UAA24883; Mon, 6 Jul 1998 20:03:46 +0200 Date: Mon, 6 Jul 1998 20:03:46 +0200 Message-Id: <199807061803.UAA24883@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: kzm@cisco.com CC: disman@nexen.com, snmpv3@tis.com In-reply-to: <199807061718.KAA11219@foxhound.cisco.com> (message from Keith McCloghrie on Mon, 6 Jul 1998 10:17:59 -0700 (PDT)) Subject: Re: VACM and DISMAN References: <199807061718.KAA11219@foxhound.cisco.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII >>>>> Keith McCloghrie writes: Keith> As I understood your proposal, each iteration of the "loop" Keith> that you proposed was to test a particular group's access Keith> privileges, so that the number of times around the loop is the Keith> number of groups that a user is in, i.e., denying an access for Keith> a user in N groups is N times as much checking as denying a Keith> user in one group. That's what I meant by multiplicative. Keith> This is independent of GetNext/GetBulk. However, N times a Keith> larger number is a larger absolute/more noticeable increase, Keith> and so it's GetNext performance which appears to suffer most. You are right that a user in N groups requires to repeat the check N times in the worst case. So you will have N * M checks in the worst case if the average number of subtrees defined for each group is M. However, I argue that without having this feature, people will be forced to create VACM configurations with N * M subtree definitions for a given user since you can not share definitions. So you will gain nothing in the isAccessAllowed() function (you still need to do N * M tests in the worst case) but you will pay be a high price in terms of the total number of VACM MIB entries needed and the complexity a security administrator has to deal with. I would also expect that the number of discarded method function calls during GetNext processing defines the performance bottleneck and not the number of access control rules you have to check. (The later one is a tight loop while the method function calls very likely include costly interactions with a hardware device or a subagent.) And the number of discarded method function calls depends on how simple or complex the access control configuration is and how intelligent the agent is to skip method function calls that are known to be out of scope with regard to the access control rules. 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 maria@xedia.com Mon Jul 6 19:43: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 TAA01444 for ; Mon, 6 Jul 1998 19:43:55 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id TAA22295 for ; Mon, 6 Jul 1998 19:43:35 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma022291; Mon, 6 Jul 98 19:43:17 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id TAA01413 for ; Mon, 6 Jul 1998 19:42:44 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma001324; Mon, 6 Jul 98 19:42:15 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id TAA08049; Mon, 6 Jul 1998 19:42:45 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id RAA18541 for ; Mon, 6 Jul 1998 17:42:38 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id TAA22262 for ; Mon, 6 Jul 1998 19:42:35 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma022252; Mon, 6 Jul 98 19:42:33 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom (8.8.5/8.7.3) with ESMTP id UAA21810 for ; Mon, 6 Jul 1998 20:15:49 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id UAA03711 for ; Mon, 6 Jul 1998 20:15:48 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id TAA21152 for ; Mon, 6 Jul 1998 19:15:46 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma021147; Mon, 6 Jul 98 19:15:42 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id TAA22729 for ; Mon, 6 Jul 1998 19:15:09 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma022668; Mon, 6 Jul 98 19:14:51 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id TAA02490; Mon, 6 Jul 1998 19:15:21 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA17489; Mon, 6 Jul 1998 17:15:20 -0700 (PDT) Date: Mon, 6 Jul 1998 17:15:20 -0700 (PDT) From: Randy Presuhn Message-Id: <199807070015.RAA17489@dorothy.bmc.com> To: disman@nexen.com, snmpv3@tis.com Subject: Re: VACM and DISMAN Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi- > Date: Mon, 6 Jul 1998 20:03:46 +0200 > From: Juergen Schoenwaelder > To: kzm@cisco.com > CC: disman@nexen.com, snmpv3@tis.com > Subject: Re: VACM and DISMAN > References: <199807061718.KAA11219@foxhound.cisco.com> > > > >>>>> Keith McCloghrie writes: > > Keith> As I understood your proposal, each iteration of the "loop" > Keith> that you proposed was to test a particular group's access > Keith> privileges, so that the number of times around the loop is the > Keith> number of groups that a user is in, i.e., denying an access for > Keith> a user in N groups is N times as much checking as denying a > Keith> user in one group. That's what I meant by multiplicative. > Keith> This is independent of GetNext/GetBulk. However, N times a > Keith> larger number is a larger absolute/more noticeable increase, > Keith> and so it's GetNext performance which appears to suffer most. > > You are right that a user in N groups requires to repeat the check N > times in the worst case. So you will have N * M checks in the worst > case if the average number of subtrees defined for each group is M. > > However, I argue that without having this feature, people will be > forced to create VACM configurations with N * M subtree definitions > for a given user since you can not share definitions. So you will gain > nothing in the isAccessAllowed() function (you still need to do N * M > tests in the worst case) but you will pay be a high price in terms of > the total number of VACM MIB entries needed and the complexity a > security administrator has to deal with. ... It seems like the other appropach you outlined makes more sense, where the administrator defines for each user a set of _in_ securityNames with the supporting USM entries and vacmSecurityToGroupEntries. In this case, one would only need groups and avoid excessive duplication of subtree information. The downside is that the command generator would have to be explicit about the role in which the user is acting, and the security administrator would need to be aware of those roles. This is probably not a bad thing. ----------------------------------------------------------------------- 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 maria@xedia.com Tue Jul 7 04:42:48 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 EAA01677 for ; Tue, 7 Jul 1998 04:42:47 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id EAA13798 for ; Tue, 7 Jul 1998 04:42:27 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma013783; Tue, 7 Jul 98 04:42:00 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id EAA11457 for ; Tue, 7 Jul 1998 04:41:27 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma011451; Tue, 7 Jul 98 04:41:26 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id EAA17892; Tue, 7 Jul 1998 04:41:57 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id CAA04877 for ; Tue, 7 Jul 1998 02:41:55 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id EAA02634 for ; Tue, 7 Jul 1998 04:41:54 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma002632; Tue, 7 Jul 98 04:41:47 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom (8.8.5/8.7.3) with ESMTP id FAA28505 for ; Tue, 7 Jul 1998 05:04:58 -0400 (EDT) Received: from ra.ibr.cs.tu-bs.de (ra.ibr.cs.tu-bs.de [134.169.34.12]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id FAA25946 for ; Tue, 7 Jul 1998 05:04:49 -0400 (EDT) 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 LAA21425; Tue, 7 Jul 1998 11:04:42 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id LAA01088; Tue, 7 Jul 1998 11:04:37 +0200 Date: Tue, 7 Jul 1998 11:04:37 +0200 Message-Id: <199807070904.LAA01088@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: rpresuhn@dorothy.bmc.com CC: disman@nexen.com, snmpv3@tis.com In-reply-to: <199807070015.RAA17489@dorothy.bmc.com> (message from Randy Presuhn on Mon, 6 Jul 1998 17:15:20 -0700 (PDT)) Subject: Re: VACM and DISMAN References: <199807070015.RAA17489@dorothy.bmc.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII >>>>> Randy Presuhn writes: Randy> It seems like the other appropach you outlined makes more Randy> sense, where the administrator defines for each user a set of Randy> _in_ securityNames with the supporting USM entries Randy> and vacmSecurityToGroupEntries. In this case, one would only Randy> need groups and avoid excessive duplication of subtree Randy> information. The downside is that the command generator would Randy> have to be explicit about the role in which the user is acting, Randy> and the security administrator would need to be aware of those Randy> roles. This is probably not a bad thing. I have concerns that this matches the expectations of SNMPv3 end users. I also have concerns that management applications will provide the support necessary to make this work in practice (that is providing the intelligence to automatically select the "right" identities). The lesson I have learned from party-based SNMPv2 is that the stuff has to be damn simple to use and that we should not rely on assistance from tools to get the thing configured and running. 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 maria@xedia.com Tue Jul 7 05:10: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 FAA01685 for ; Tue, 7 Jul 1998 05:10:57 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id FAA14944 for ; Tue, 7 Jul 1998 05:10:37 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma014932; Tue, 7 Jul 98 05:10:07 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id FAA19351 for ; Tue, 7 Jul 1998 05:09:34 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma019205; Tue, 7 Jul 98 05:09:06 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id FAA23318; Tue, 7 Jul 1998 05:09:37 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id DAA05687 for ; Tue, 7 Jul 1998 03:09:36 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id FAA14910 for ; Tue, 7 Jul 1998 05:09:35 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma014893; Tue, 7 Jul 98 05:09:15 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom (8.8.5/8.7.3) with ESMTP id FAA29084 for ; Tue, 7 Jul 1998 05:50:02 -0400 (EDT) Received: from VNET.IBM.COM (vnet.ibm.com [204.146.168.194]) by guelah.nexen.com (8.8.5/8.7.3) with SMTP id FAA04526 for ; Tue, 7 Jul 1998 05:49:57 -0400 (EDT) Message-Id: <199807070949.FAA04526@guelah.nexen.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R4) with BSMTP id 4436; Tue, 07 Jul 98 05:49:53 EDT Date: Tue, 7 Jul 98 11:50:54 DST From: "Bert Wijnen" To: schoenw@ibr.cs.tu-bs.de, rpresuhn@dorothy.bmc.com cc: disman@nexen.com, snmpv3@tis.com Subject: VACM and DISMAN Ref: Your note of Tue, 7 Jul 1998 11:04:37 +0200 Subject: Re: VACM and DISMAN Randy and Juergen discuss: > Randy> It seems like the other appropach you outlined makes more > Randy> sense, where the administrator defines for each user a set of > Randy> _in_ securityNames with the supporting USM entries > Randy> and vacmSecurityToGroupEntries. In this case, one would only > Randy> need groups and avoid excessive duplication of subtree > Randy> information. The downside is that the command generator would > Randy> have to be explicit about the role in which the user is acting, > Randy> and the security administrator would need to be aware of those > Randy> roles. This is probably not a bad thing. > > I have concerns that this matches the expectations of SNMPv3 end > users. I also have concerns that management applications will provide > the support necessary to make this work in practice (that is providing > the intelligence to automatically select the "right" identities). The > lesson I have learned from party-based SNMPv2 is that the stuff has to > be damn simple to use and that we should not rely on assistance from > tools to get the thing configured and running. > Well... I have tried to look at this if I were in the shoes of a Network Manager of a BIG company... (I am not so maybe some real people in this role can jump in and tell us the real story). I know that SNMpv3 allows me to add/delete users via SNMP. Now imagine, that I get a new employee Joe. WHat do I do? Do I want to add user Joe to all my SNMP engines (say some 10 or 100 thousand)? That may take a while before it is complete. Then... after a few months, Joe decides to go and work somewhere else. Do I then delete user Joe at those 10 or 100 thousand SNMP engines? I would rather have a NMS that internally uses SNMP-users in the form of "operator-role", "networ-admin-role", "senior-role", "junior-role", "security-admin-role" and so on. I would then want the NMS to let me add a user Joe and tell the NMS that Joe gets to work with the "junior-role" for now... maybe later as the "senior-role" once he proves he is good and can be trusted. When Joe leaves, I have these advantages: - I do no have to delete him 10 or 100 thousand times (which could take to long from a security point of view). - Even if I do not delete him immeediately from the NMS definitions, these NMSes are probably in well-protected areas, so I would not be in such a big hurry. But in any event, now I would only have to disable Joe in a few NMSes as opposed to thousands of SNMP engines. - The real SNMP secrets can actually be todally hidden from human users/operators. I think I would also want to have a few "fire-fighting" SNMP users at all SNMP entities for emergency situations. These would be very strictly controlled. Now... real network-manager, pls speak up. How do you want to exploit SNMPv3 in your operational environment? Bert From maria@xedia.com Tue Jul 7 07:30: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 HAA01725 for ; Tue, 7 Jul 1998 07:30:39 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id HAA20222 for ; Tue, 7 Jul 1998 07:30:17 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma020202; Tue, 7 Jul 98 07:29:52 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id HAA01074 for ; Tue, 7 Jul 1998 07:29:20 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma001045; Tue, 7 Jul 98 07:29:14 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id HAA20907; Tue, 7 Jul 1998 07:29:45 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id FAA09835 for ; Tue, 7 Jul 1998 05:29:44 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id HAA05957 for ; Tue, 7 Jul 1998 07:29:43 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma005953; Tue, 7 Jul 98 07:29:26 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom (8.8.5/8.7.3) with ESMTP id IAA00926 for ; Tue, 7 Jul 1998 08:05:15 -0400 (EDT) Received: from relay9.uu.net (relay9.uu.net [192.48.96.85]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id IAA04831 for ; Tue, 7 Jul 1998 08:05:15 -0400 (EDT) Received: from neserve0.uu.net by relay9.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQewzo16983; Tue, 7 Jul 1998 08:05:13 -0400 (EDT) Received: from localhost by neserve0.uu.net with SMTP (peer crosschecked as: mo@localhost) id QQewzo24798; Tue, 7 Jul 1998 08:05:12 -0400 (EDT) Message-Id: To: "Bert Wijnen" cc: schoenw@ibr.cs.tu-bs.de, rpresuhn@dorothy.bmc.com, disman@nexen.com, snmpv3@tis.com Subject: Re: VACM and DISMAN In-reply-to: Your message of "Tue, 07 Jul 1998 11:50:54 +0700." <199807070946.FAA18537@relay.hq.tis.com> Date: Tue, 07 Jul 1998 08:05:12 -0400 From: "Mike O'Dell" for my money (and UUNET's), we believe that time-varying role-based security policy is the only way you deal with humans, which is very distinct from network elements. for example, a network operator on duty may have significant access rights to test and reconfigure a network element, but when the person goes off-shift, they must lose those rights. the only way to do this rationally is to do the mapping of person-role-time-rights *mostly* in NMS software which sits between the operator and the network elements. the machinery in SNMPv3 supports identity-rights mappings, and that is sufficient given the interposed NMS software which uses a set of identities instantiated in the network elements to map a given person performing a specific role at a certain time into a set of required access rights. Note that the "time" part is *only* done in the NMS - that's waaaaay too messy to put in network elements because of things like time zones, shift changes, etc, etc. while one can describe all kinds of access control policies, the question is one of partitioning - how much is supported directly by the network element and how much by layered NMS functionality. Until proven otherwise, we are proceeding with the firm belief that what's currently in SNMPv3 is enough mechanism upon which to build the complex policy machinery we need using external software, and that making the mechanism inside the network elements more complex is probably at the point of diminishing returns, for all the reasons Bert mentioned. -mo From maria@xedia.com Tue Jul 14 15:20:06 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 PAA01823 for ; Tue, 14 Jul 1998 15:20:05 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA12199 for ; Tue, 14 Jul 1998 15:19:29 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma012190; Tue, 14 Jul 98 15:19:24 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id PAA26358 for ; Tue, 14 Jul 1998 15:18:51 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma025979; Tue, 14 Jul 98 15:18:26 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id PAA19456; Tue, 14 Jul 1998 15:18:49 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA13979 for ; Tue, 14 Jul 1998 13:18:43 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id PAA24935 for ; Tue, 14 Jul 1998 15:18:37 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma024913; Tue, 14 Jul 98 15:18:34 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom (8.8.5/8.7.3) with ESMTP id PAA02980 for ; Tue, 14 Jul 1998 15:42:08 -0400 (EDT) From: TrainingFocus@abbie.com Received: from arcturus.worldwidenews.net (guardian.wwncorp.net [206.129.59.6]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id PAA02944 for ; Tue, 14 Jul 1998 15:42:07 -0400 (EDT) Date: Tue, 14 Jul 1998 15:42:07 -0400 (EDT) Message-Id: <199807141942.PAA02944@nexen.nexen.com> Received: from pacbell.net ([207.214.148.33]) by arcturus.worldwidenews.net (Post.Office MTA v3.1.2 release (PO205-101c) ID# 507-49073U1100L200S0) with SMTP id AAA204 for ; Tue, 14 Jul 1998 12:51:49 -0700 To: disman@nexen.com Subject: "Sexual Harassment" ~ #1 business video This #1 best-selling, business training video can save you thousands of dollars in legal problems by preventing sexual harassment situations before they start. "Sexual Harassment: Situations for Discussion" ~ VHS Video 24 minutes (1998) Includes a 112-page self-study book "Stopping Sexual Harassment Before it Starts: A Business and Legal Perspective" ($12.95 value) ~ Price: US$99.95 + $8.00 Federal Express 3-day (US) shipping ~ Absolute 100% satisfaction, money-back guarantee ~ Produced by the leading US producer of business training videos For complete details, please call toll-free anytime... 800-700-4439 (US only) We apologize if our phone lines are busy, please keep trying. It's a flat-rate, unlimited-volume 800# system using the latest telecom technology. But occaisionally we do overwhelm it. No organization can afford to ignore sexual harassment prevention training. This new, quality, professionally-produced, video training program delivers the facts on what managers and employees need to know for sexual harassment recognition and prevention. Two new, landmark, US Supreme Court rulings ( 6/26/98 ) make it easier to bring lawsuits over sexual harassment at work. In a resounding 7-2 vote, the nation's high court ruled in two cases that employers may be held liable for misconduct by their supervisors. Sexual harassment lawsuits have soared nationwide during the 1990s. WASHINGTON (Reuters) http://www.infobeat.com/stories/cgi/story.cgi?id=2554810315-203 Thank you. Visa, Mastercard, American Express accepted. Orders are shipped within 24 hours via 3-day Federal Express.. Outside the continental US, please ask for shipping charges. TWO WAYS TO ORDER: 1) Please call toll-free anytime 800-700-4439 (US only) You may leave your complete order information or leave your name and telephone number and we will call you. 2) Print this email (with order form below) and mail it with your check or credit card information to: TrainingFocus, Inc. 2777 Yulupa Avenue #133 Santa Rosa, California, 95405 Internet Distributor of Quality, Professionally-Produced, Affordable, Business Videos, Books, Audios, and CDs - since 1996 By using the Internet to eliminate high costs of printing and postage, we are able to sell at prices around US$100. Similar quality products cost US$250 - US$800 elsewhere. Please ask about our catalog of hundreds of new and best-selling, quality, affordable business training videos. .............ORDER FORM.................. Sexual Harassment: Situations for Discussion - video and book US$ 99.95 + $8.00 Federal Express 3-day shipping (US) {for multiple orders add shipping charge of $2.00 each ) Total US$107.95 100% satisfaction, money-back guarantee by simply returning the product. Further, you always have complete recourse through your credit card bank if you are not completely satisfied with either the product or our service. Quantity: _1_ $107.95 total includes shipping Name: Company: Street Address: City-State-Province: Country-Postal Code:: Phone: Fax: Email - if you want new releases announcements: Visa - Mastercard- American Express: Card Number: Expiration Date: CardHolder Name: Bank telephone 800# on back of card: Signature Date .................. thank you. From maria@xedia.com Tue Jul 14 17:20: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 RAA01856 for ; Tue, 14 Jul 1998 17:20:55 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA18856 for ; Tue, 14 Jul 1998 17:20:19 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma018849; Tue, 14 Jul 98 17:19:59 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA08323 for ; Tue, 14 Jul 1998 17:19:26 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma008232; Tue, 14 Jul 98 17:19:20 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id RAA25283; Tue, 14 Jul 1998 17:19:52 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id PAA15219 for ; Tue, 14 Jul 1998 15:19:50 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA18840 for ; Tue, 14 Jul 1998 17:19:49 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma018825; Tue, 14 Jul 98 17:19:39 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom (8.8.5/8.7.3) with ESMTP id RAA06721 for ; Tue, 14 Jul 1998 17:51:52 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id RAA04642 for ; Tue, 14 Jul 1998 17:54:24 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA17759 for ; Tue, 14 Jul 1998 16:54:19 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma017754; Tue, 14 Jul 98 16:54:12 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA11286 for ; Tue, 14 Jul 1998 16:53:38 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma010881; Tue, 14 Jul 98 16:53:16 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA17639 for ; Tue, 14 Jul 1998 16:53:48 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA14922 for disman@nexen.com; Tue, 14 Jul 1998 14:53:47 -0700 (PDT) Date: Tue, 14 Jul 1998 14:53:47 -0700 (PDT) From: Randy Presuhn Message-Id: <199807142153.OAA14922@dorothy.bmc.com> To: disman@nexen.com Subject: Script MIB comments? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - Are there any remaining issues with the Script MIB as posted in ? If not, I'll issue working group last call on Friday, July 17. ----------------------------------------------------------------------- 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 maria@xedia.com Tue Jul 14 17:21:27 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 RAA01860 for ; Tue, 14 Jul 1998 17:21:26 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA18890 for ; Tue, 14 Jul 1998 17:20:49 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma018873; Tue, 14 Jul 98 17:20:29 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA08792 for ; Tue, 14 Jul 1998 17:19:55 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma008506; Tue, 14 Jul 98 17:19:37 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id RAA25340; Tue, 14 Jul 1998 17:20:09 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id PAA15228 for ; Tue, 14 Jul 1998 15:20:07 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id RAA02678 for ; Tue, 14 Jul 1998 17:20:06 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma002639; Tue, 14 Jul 98 17:19:56 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom (8.8.5/8.7.3) with ESMTP id RAA06695 for ; Tue, 14 Jul 1998 17:50:30 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id RAA04624 for ; Tue, 14 Jul 1998 17:52:50 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA17722 for ; Tue, 14 Jul 1998 16:52:49 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma017720; Tue, 14 Jul 98 16:52:41 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA09794 for ; Tue, 14 Jul 1998 16:52:08 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma009781; Tue, 14 Jul 98 16:52:07 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA17321 for ; Tue, 14 Jul 1998 16:52:39 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA14881 for disman@nexen.com; Tue, 14 Jul 1998 14:52:38 -0700 (PDT) Date: Tue, 14 Jul 1998 14:52:38 -0700 (PDT) From: Randy Presuhn Message-Id: <199807142152.OAA14881@dorothy.bmc.com> To: disman@nexen.com Subject: Schedule MIB comments? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - Are there any remaining issues with the Schedule MIB as posted in ? If not, I'll issue working group last call on Friday, July 17. ----------------------------------------------------------------------- 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 maria@xedia.com Wed Jul 15 04:37:33 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 EAA06278 for ; Wed, 15 Jul 1998 04:37:32 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id EAA09790 for ; Wed, 15 Jul 1998 04:36:55 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma009784; Wed, 15 Jul 98 04:36:39 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id EAA29333 for ; Wed, 15 Jul 1998 04:36:06 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma029223; Wed, 15 Jul 98 04:35:52 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id EAA16868; Wed, 15 Jul 1998 04:36:24 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id CAA08977 for ; Wed, 15 Jul 1998 02:36:18 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id EAA09719 for ; Wed, 15 Jul 1998 04:36:16 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma009674; Wed, 15 Jul 98 04:36:08 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom (8.8.5/8.7.3) with ESMTP id EAA17039 for ; Wed, 15 Jul 1998 04:45:24 -0400 (EDT) Received: from ra.ibr.cs.tu-bs.de (ra.ibr.cs.tu-bs.de [134.169.34.12]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id FAA05875 for ; Wed, 15 Jul 1998 05:10:28 -0400 (EDT) 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 LAA23822; Wed, 15 Jul 1998 11:10:26 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id LAA05333; Wed, 15 Jul 1998 11:10:25 +0200 Date: Wed, 15 Jul 1998 11:10:25 +0200 Message-Id: <199807150910.LAA05333@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: rpresuhn@dorothy.bmc.com CC: disman@nexen.com In-reply-to: <199807142153.OAA14922@dorothy.bmc.com> (message from Randy Presuhn on Tue, 14 Jul 1998 14:53:47 -0700 (PDT)) Subject: Re: Script MIB comments? References: <199807142153.OAA14922@dorothy.bmc.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII >>>>> Randy Presuhn writes: Randy> Are there any remaining issues with the Script MIB as posted in Randy> ? - The description of smRunControl refers to the smRunState value `completed' which does not exist anymore. - I am working with David on an example which explains how to configure VACM. Randy> If not, I'll issue working group last call on Friday, July 17. I can try to submit a new ID which addresses these issues. David is currently reviewing the example. I have no idea whether the draft will be in the official archive by Friday. Juergen Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3289) From maria@xedia.com Wed Jul 15 04:38:32 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 EAA06296 for ; Wed, 15 Jul 1998 04:38:32 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id EAA09814 for ; Wed, 15 Jul 1998 04:37:55 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma009804; Wed, 15 Jul 98 04:37:40 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id EAA29762 for ; Wed, 15 Jul 1998 04:37:06 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma029608; Wed, 15 Jul 98 04:36:48 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id EAA17075; Wed, 15 Jul 1998 04:37:20 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id CAA08982 for ; Wed, 15 Jul 1998 02:37:18 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id EAA27978 for ; Wed, 15 Jul 1998 04:37:17 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma027969; Wed, 15 Jul 98 04:36:48 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom (8.8.5/8.7.3) with ESMTP id EAA17015 for ; Wed, 15 Jul 1998 04:41:39 -0400 (EDT) Received: from ra.ibr.cs.tu-bs.de (ra.ibr.cs.tu-bs.de [134.169.34.12]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id FAA05867 for ; Wed, 15 Jul 1998 05:06:35 -0400 (EDT) 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 KAA22982; Wed, 15 Jul 1998 10:42:47 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id KAA04552; Wed, 15 Jul 1998 10:25:06 +0200 Date: Wed, 15 Jul 1998 10:25:06 +0200 Message-Id: <199807150825.KAA04552@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: rpresuhn@dorothy.bmc.com CC: disman@nexen.com In-reply-to: <199807142152.OAA14881@dorothy.bmc.com> (message from Randy Presuhn on Tue, 14 Jul 1998 14:52:38 -0700 (PDT)) Subject: Re: Schedule MIB comments? References: <199807142152.OAA14881@dorothy.bmc.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII >>>>> Randy Presuhn writes: Randy> Are there any remaining issues with the Schedule MIB as posted Randy> in ? - The example in this draft does not match the current version of the Script MIB. - The MIB module name should be changed to DISMAN-SCHEDULE-MIB. - I would like to get rid of the IMPLIED keyword to allow table expansions. Randy> If not, I'll issue working group last call on Friday, July 17. I can try to submit a new ID with these fixes until Friday, but I do not know if it will be in the official place by Friday. Juergen Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3289) From maria@xedia.com Wed Jul 15 14:14:20 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 OAA10883 for ; Wed, 15 Jul 1998 14:14:19 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA08853 for ; Wed, 15 Jul 1998 14:13:42 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma008847; Wed, 15 Jul 98 14:13:36 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA25773 for ; Wed, 15 Jul 1998 14:13:02 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma025707; Wed, 15 Jul 98 14:12:57 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id OAA23680; Wed, 15 Jul 1998 14:13:29 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA20222 for ; Wed, 15 Jul 1998 12:13:20 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id OAA00962 for ; Wed, 15 Jul 1998 14:13:18 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma000925; Wed, 15 Jul 98 14:12:47 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom (8.8.5/8.7.3) with ESMTP id NAA01194 for ; Wed, 15 Jul 1998 13:55:25 -0400 (EDT) Received: from ALPHA1.RESTON.MCI.NET (alpha1.Reston.mci.net [204.70.128.80]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id OAA10595 for ; Wed, 15 Jul 1998 14:40:33 -0400 (EDT) Received: from rfrye.reston.mci.net ([166.45.4.242]) by ALPHA1.RESTON.MCI.NET (PMDF V5.2-22 #3857) with SMTP id <01IZFLPOBVHQ00022O@ALPHA1.RESTON.MCI.NET> for disman@nexen.com; Wed, 15 Jul 1998 14:40:20 EDT Date: Wed, 15 Jul 1998 13:56:09 -0400 From: Rob Frye Subject: Re: VACM and DISMAN In-reply-to: X-Sender: rfrye@alpha1.reston.mci.net To: "Mike O'Dell" , Bert Wijnen Cc: disman@nexen.com, snmpv3@tis.com Message-id: MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Content-type: text/plain; charset="us-ascii" References: <"Your message of Tue, 07 Jul 1998 11:50:54 +0700." <199807070946.FAA18537@relay.hq.tis.com> At 08:05 AM 7/7/98 , Mike O'Dell wrote: >for my money (and UUNET's), we believe that time-varying >role-based security policy is the only way you deal with >humans, which is very distinct from network elements. Agreed, Mike. Bert Wijnen said: >I know that SNMpv3 allows me to add/delete users via SNMP. >Now imagine, that I get a new employee Joe. WHat do I do? >Do I want to add user Joe to all my SNMP engines (say some 10 or 100 >thousand)? That may take a while before it is complete. >Then... after a few months, Joe decides to go and work somewhere else. >Do I then delete user Joe at those 10 or 100 thousand SNMP engines? > >I would rather have a NMS that internally uses SNMP-users in the form >of "operator-role", "networ-admin-role", "senior-role", "junior-role", >"security-admin-role" and so on. I would then want the NMS to >let me add a user Joe and tell the NMS that Joe gets to work with >the "junior-role" for now... maybe later as the "senior-role" once he >proves he is good and can be trusted. and Mike: >the only way to do this rationally is to do the mapping of >person-role-time-rights *mostly* in NMS software which sits >between the operator and the network elements. One problem with relying on the NMS software to translate "joe" to "junior-role", "operator-role" or "senior-role" is that it is also doing that for users "fred", "sam", "sally" and the rest. Unless the NMS is the only way that these users can and do access the network elements (not counting your 3rd-level network gurus who telnet in when all else fails), you have somewhat of an audit trail problem. If the agent records the fact that "senior-role" changed X to Y at time T, and someone is pulling out their hair trying to figure out why the network went down at time T, it's awfully hard to find out it was "joe" rather than "sam". And for a "real network-manager" in a BIG company (per Bert), the ability to know who changed what when is important. I agree that the NMS needs to handle the time domain aspects, and that the roles and individuals are known there. But I don't like having all users mapped to roles, where only the role-level security is known to the Agents. The configuration complexities have been noted by Juergen, T. Max, Keith and others; my reading says its a fairly close tradeoff, with more and more complexity using group mappings in a fluid environment. -- Rob. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Rob Frye ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sr. Network Management Architect Email: rfrye@mci.net MCI Telecommunications Corp. Phone: +1-703-715-7225/V272-7225 2100 Reston Parkway, Suite 600 Fax: +1-703-715-7436 Reston, VA 20191 Pager: +1-888-270-1537 ~~~~~~~~~~~~~~~~~~~~~~~~Procrastinate Later~~~~~~~~~~~~~~~~~~~~~~~~ From maria@xedia.com Wed Jul 15 14:14: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 OAA10881 for ; Wed, 15 Jul 1998 14:14:19 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA08851 for ; Wed, 15 Jul 1998 14:13:42 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma008846; Wed, 15 Jul 98 14:13:36 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA25772 for ; Wed, 15 Jul 1998 14:13:02 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma025660; Wed, 15 Jul 98 14:12:54 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id OAA23626; Wed, 15 Jul 1998 14:13:19 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA20207 for ; Wed, 15 Jul 1998 12:13:13 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA08833 for ; Wed, 15 Jul 1998 14:13:11 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma008831; Wed, 15 Jul 98 14:12:43 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom (8.8.5/8.7.3) with ESMTP id OAA01478 for ; Wed, 15 Jul 1998 14:04:36 -0400 (EDT) Received: from relay9.uu.net (relay9.uu.net [192.48.96.85]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id OAA07970 for ; Wed, 15 Jul 1998 14:50:07 -0400 (EDT) Received: from neserve0.uu.net by relay9.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQeyed17648; Wed, 15 Jul 1998 14:50:05 -0400 (EDT) Received: from localhost by neserve0.uu.net with SMTP (peer crosschecked as: mo@localhost) id QQeyed26145; Wed, 15 Jul 1998 14:50:03 -0400 (EDT) Message-Id: To: Rob Frye cc: "Mike O'Dell" , Bert Wijnen , disman@nexen.com, snmpv3@tis.com, mo@UU.NET Subject: Re: VACM and DISMAN In-reply-to: Your message of "Wed, 15 Jul 1998 13:56:09 EDT." Date: Wed, 15 Jul 1998 14:50:03 -0400 From: "Mike O'Dell" if the NMS is doing the authority mapping and not keeping audit trails, the implementation is deeply defective -mo From maria@xedia.com Wed Jul 15 15:04: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 PAA11282 for ; Wed, 15 Jul 1998 15:04:35 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA12036 for ; Wed, 15 Jul 1998 15:03:57 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma012024; Wed, 15 Jul 98 15:03:50 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id PAA11847 for ; Wed, 15 Jul 1998 15:03:16 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma011561; Wed, 15 Jul 98 15:02:58 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id PAA09208; Wed, 15 Jul 1998 15:03:29 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA25314 for ; Wed, 15 Jul 1998 13:03:28 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA12008 for ; Wed, 15 Jul 1998 15:03:27 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma012001; Wed, 15 Jul 98 15:03:00 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom (8.8.5/8.7.3) with ESMTP id OAA02411 for ; Wed, 15 Jul 1998 14:32:38 -0400 (EDT) Received: from ALPHA1.RESTON.MCI.NET (alpha1.Reston.mci.net [204.70.128.80]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id PAA10970 for ; Wed, 15 Jul 1998 15:19:18 -0400 (EDT) Received: from rfrye.reston.mci.net ([166.45.4.242]) by ALPHA1.RESTON.MCI.NET (PMDF V5.2-22 #3857) with SMTP id <01IZFN302LKM000288@ALPHA1.RESTON.MCI.NET> for disman@nexen.com; Wed, 15 Jul 1998 15:19:16 EDT Date: Wed, 15 Jul 1998 15:09:49 -0400 From: Rob Frye Subject: Re: VACM and DISMAN X-Sender: rfrye@alpha1.reston.mci.net To: "Mike O'Dell" Cc: "Mike O'Dell" , Bert Wijnen , disman@nexen.com, snmpv3@tis.com, mo@UU.NET Message-id: <01IZFN303GNS000288@ALPHA1.RESTON.MCI.NET> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Content-type: text/plain; charset="us-ascii" At 02:50 PM 7/15/98 , Mike O'Dell wrote: >if the NMS is doing the authority mapping and not keeping >audit trails, the implementation is deeply defective Agreed. The problem is >Unless the NMS is the only way that these users can >and do access the network elements... If there are multiple independent systems, then there needs to be a mechanism to consolidate the audit info from them all. -- Rob. From maria@xedia.com Wed Jul 15 17:13: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 RAA12306 for ; Wed, 15 Jul 1998 17:13:15 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA18666 for ; Wed, 15 Jul 1998 17:12:37 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma018567; Wed, 15 Jul 98 17:11:54 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA28055 for ; Wed, 15 Jul 1998 17:11:20 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma027724; Wed, 15 Jul 98 17:10:55 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id RAA15212; Wed, 15 Jul 1998 17:11:25 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id PAA27830 for ; Wed, 15 Jul 1998 15:11:19 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA18444 for ; Wed, 15 Jul 1998 17:11:17 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma018337; Wed, 15 Jul 98 17:11:02 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom (8.8.5/8.7.3) with ESMTP id QAA06063 for ; Wed, 15 Jul 1998 16:48:12 -0400 (EDT) Received: from apollo.scram.de (apollo.scram.de [194.162.91.67]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id RAA11894 for ; Wed, 15 Jul 1998 17:40:09 -0400 (EDT) Received: from neptun.nwe.de ([192.168.99.20]) by apollo.scram.de (8.9.0/8.9.0) with ESMTP id XAA17471; Wed, 15 Jul 1998 23:40:12 +0200 (MESZ) Received: from localhost (localhost [[UNIX: localhost]]) by neptun.nwe.de (8.8.8/8.8.8) with SMTP id XAA14226; Wed, 15 Jul 1998 23:40:01 +0200 (CEST) Date: Wed, 15 Jul 1998 23:40:00 +0200 (CEST) From: Jochen Friedrich X-Sender: jochen@neptun.nwe.de To: "Mike O'Dell" cc: Rob Frye , Bert Wijnen , disman@nexen.com, snmpv3@tis.com Subject: Re: VACM and DISMAN In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 15 Jul 1998, Mike O'Dell wrote: > if the NMS is doing the authority mapping and not keeping > audit trails, the implementation is deeply defective Sure. But now these NMS audit trails become very important. If they get lost (either by accident or on purpose), it's no longer possible to trace back to the original user. In the case of the agents doing the mapping, it's much harder to manipulate all audit trails. Jochen From maria@xedia.com Wed Jul 15 17:17: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 RAA12336 for ; Wed, 15 Jul 1998 17:17:26 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA18903 for ; Wed, 15 Jul 1998 17:16:48 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma018897; Wed, 15 Jul 98 17:16:29 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA02854 for ; Wed, 15 Jul 1998 17:15:56 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma002753; Wed, 15 Jul 98 17:15:48 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id RAA16565; Wed, 15 Jul 1998 17:16:20 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id PAA27856 for ; Wed, 15 Jul 1998 15:16:19 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA18884 for ; Wed, 15 Jul 1998 17:16:18 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma018876; Wed, 15 Jul 98 17:15:59 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA02503 for ; Wed, 15 Jul 1998 17:15:25 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by dresden.bmc.com via smap (3.2) id xma002135; Wed, 15 Jul 98 17:15:06 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom (8.8.5/8.7.3) with ESMTP id QAA06060 for ; Wed, 15 Jul 1998 16:48:02 -0400 (EDT) Received: from relay8.uu.net (relay8.uu.net [192.48.96.84]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id RAA11878 for ; Wed, 15 Jul 1998 17:40:00 -0400 (EDT) Received: from neserve0.uu.net by relay8.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQeyeo13848; Wed, 15 Jul 1998 17:39:53 -0400 (EDT) Received: from localhost by neserve0.uu.net with SMTP (peer crosschecked as: mo@localhost) id QQeyeo07527; Wed, 15 Jul 1998 17:39:52 -0400 (EDT) Message-Id: To: Rob Frye cc: "Mike O'Dell" , Bert Wijnen , disman@nexen.com, snmpv3@tis.com Subject: Re: VACM and DISMAN In-reply-to: Your message of "Wed, 15 Jul 1998 15:09:49 EDT." <01IZFN303GNS000288@ALPHA1.RESTON.MCI.NET> Date: Wed, 15 Jul 1998 17:39:52 -0400 From: "Mike O'Dell" "Doctor! Doctor! It hurts when I do this!" "Then don't do that!" -mo From maria@xedia.com Thu Jul 16 01:06: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 BAA16118 for ; Thu, 16 Jul 1998 01:06:42 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id BAA02958 for ; Thu, 16 Jul 1998 01:06:04 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma002943; Thu, 16 Jul 98 01:05:38 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id BAA16831 for ; Thu, 16 Jul 1998 01:05:04 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma016797; Thu, 16 Jul 98 01:04:49 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id BAA13579; Thu, 16 Jul 1998 01:05:18 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id XAA07330 for ; Wed, 15 Jul 1998 23:05:13 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id BAA01040 for ; Thu, 16 Jul 1998 01:04:56 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma001034; Thu, 16 Jul 98 01:04:48 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom (8.8.5/8.7.3) with ESMTP id AAA13304 for ; Thu, 16 Jul 1998 00:24:52 -0400 (EDT) Received: from pinta.kolumbus.fi (pinta.kolumbus.fi [193.229.0.40]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id BAA15223 for ; Thu, 16 Jul 1998 01:35:26 -0400 (EDT) Received: from hpylab (hpylab.rc.hpy.fi [192.126.6.2]) by pinta.kolumbus.fi (8.8.3/8.7.3) with SMTP id IAA24959 for ; Thu, 16 Jul 1998 08:35:23 +0300 (EET DST) Received: from pchni by hpylab (SMI-8.6/SMI-SVR4) id IAA20507; Thu, 16 Jul 1998 08:32:17 +0300 Message-Id: <3.0.5.32.19980716083412.00ef0e10@192.126.6.2> X-Sender: nikkanen@192.126.6.2 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 16 Jul 1998 08:34:12 +0300 To: disman@nexen.com From: Hannu Nikkanen Subject: Re: VACM and DISMAN In-Reply-To: References: <"Your message of Tue, 07 Jul 1998 11:50:54 +0700." <199807070946.FAA18537@relay.hq.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 01:56 PM 7/15/98 -0400, Rob Frye wrote: (a lot of clipping below, original text comes from a number of people on the list) >>I know that SNMpv3 allows me to add/delete users via SNMP. User rights is a security question. Usually, there is high demend to integrate security systems within the company to avoid multiple updates. Also, an emerging trend in security seems to define security servers, which all other equipment can request to OK operations (similar integration has existed in mainframes for quite a long time). Therefore, we should put requirements on access right management (say, within limit of SNMPv3 capabilities) but allow different ways to realize it. >>I would rather have a NMS that internally uses SNMP-users in the form >>of "operator-role", "networ-admin-role", "senior-role", "junior-role", >>"security-admin-role" and so on. Agree, however, one user may have a combination of roles. (A person may have several roles in work, too. Unnecessary log-off-log-in should be avoided. Also, the rights of a role could depend on the security of the access connection like remote "expert level" access requires very strong encryption" >>the only way to do this rationally is to do the mapping of >>person-role-time-rights *mostly* in NMS software which sits >>between the operator and the network elements. Or even on higher level (comment above) > >Unless the NMS is the only way that these users can >and do access the network elements (not counting your 3rd-level >network gurus who telnet in when all else fails), you have >somewhat of an audit trail problem. It never is absolutely the only way, maintenance, gurus etc have direct access anyhow. Audit trail should contain the state of the managed object before operation, operation request and state after operation. That way, one sees e.g. - that somebody (like maintenence) has changed something directly (state before operation); - in case of repeated requests, there is indication about the first success; - the results are always checked. This improves the credibility of the system, which is essential in delegation. >But I >don't like having all users mapped to roles, where only the >role-level security is known to the Agents. Actually, user roles are ment to dictate, which agents available to a user. The agents then need their own access right to network but that is not visible to the user. This does not exclude user profiles in network elements for direct access. I general, operations log (audit trail) with abundant information is very useful. One can see the history of problems and monitor access to the network, the management system itself and systems, which set requests (e.g. how often deletion of a non-existing object has been requested). Hannu From maria@xedia.com Sun Jul 19 21:40:53 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 VAA10927 for ; Sun, 19 Jul 1998 21:40:52 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id VAA04502 for ; Sun, 19 Jul 1998 21:40:06 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma004487; Sun, 19 Jul 98 21:39:45 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id VAA16628 for ; Sun, 19 Jul 1998 21:39:10 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma016523; Sun, 19 Jul 98 21:38:50 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id VAA12125; Sun, 19 Jul 1998 21:36:42 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id TAA17146 for ; Sun, 19 Jul 1998 19:36:14 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id VAA26765 for ; Sun, 19 Jul 1998 21:36:13 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma026753; Sun, 19 Jul 98 21:36:01 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id TAA02723 for ; Sun, 19 Jul 1998 19:26:19 -0400 (EDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id WAA19453 for ; Sun, 19 Jul 1998 22:04:58 -0400 (EDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id WAA28282; Sun, 19 Jul 1998 22:03:36 -0400 Received: from watpub1.watson.ibm.com (watpub1.watson.ibm.com [9.2.101.12]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id WAA06288; Sun, 19 Jul 1998 22:03:35 -0400 Received: by watpub1.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA13434; Sun, 19 Jul 1998 22:03:34 -0400 From: Uri Blumenthal Message-Id: <9807200203.AA13434@watpub1.watson.ibm.com> Subject: Re: VACM and DISMAN To: jochen+snmp3@scram.de (Jochen Friedrich) Date: Sun, 19 Jul 1998 22:03:33 -0400 (EDT) Cc: mo@UU.NET, rfrye@mci.net, WIJNEN@VNET.IBM.COM, disman@nexen.com, snmpv3@tis.com In-Reply-To: from "Jochen Friedrich" at Jul 15, 98 11:40:00 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Jochen Friedrich says: > > if the NMS is doing the authority mapping and not keeping > > audit trails, the implementation is deeply defective No argument. > Sure. But now these NMS audit trails become very important. If they get > lost (either by accident or on purpose), it's no longer possible to trace > back to the original user. > In the case of the agents doing the mapping, it's much harder to > manipulate all audit trails. It is worse than that. A sound security approach is for the OWNER of (or the CONTROLLER of the access to) the information to do the logging - otherwise it's like expecting a rogue banker to keep an audit log of all the cheats he'd done... -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From maria@xedia.com Mon Jul 20 14:07: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 OAA18551 for ; Mon, 20 Jul 1998 14:07:37 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA19363 for ; Mon, 20 Jul 1998 14:06:48 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma019356; Mon, 20 Jul 98 14:06:42 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA09730 for ; Mon, 20 Jul 1998 14:06:07 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma009639; Mon, 20 Jul 98 14:06:03 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id OAA20064; Mon, 20 Jul 1998 14:06:32 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA27714 for ; Mon, 20 Jul 1998 12:06:11 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA19293 for ; Mon, 20 Jul 1998 14:06:08 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma019196; Mon, 20 Jul 98 14:05:12 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id LAA21210 for ; Mon, 20 Jul 1998 11:45:08 -0400 (EDT) Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id OAA13063 for ; Mon, 20 Jul 1998 14:23:56 -0400 (EDT) Received: from henkell.ibr.cs.tu-bs.de (henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.1/8.9.0) with ESMTP id UAA01786; Mon, 20 Jul 1998 20:23:51 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id UAA04226; Mon, 20 Jul 1998 20:23:51 +0200 Date: Mon, 20 Jul 1998 20:23:51 +0200 Message-Id: <199807201823.UAA04226@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: internet-drafts@ietf.org CC: disman@nexen.com Subject: draft-ietf-disman-schedule-mib-04.txt Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Please post the attached document as Internet Draft . This document is created on behalf of the Distributed Management WG. Juergen Internet-Draft Schedule MIB July 1998 Definitions of Managed Objects for Scheduling Management Operations July 17, 1998 David B. Levi SNMP Research, Inc. levi@snmp.com Juergen Schoenwaelder TU Braunschweig schoenw@ibr.cs.tu-bs.de 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 ``work in progress.'' To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Please send comments to the Distributed Management Working Group, . Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Expires December 1998 [Page 1] Internet-Draft Schedule MIB July 1998 1. 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 a set of managed objects that are used to schedule management operations periodically or at specified dates and times. This memo does not specify a standard for the Internet community. 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2271 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in RFC 1155 [2], RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC 1904 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2273 [14] and the view-based access control mechanism described in RFC 2275 [15]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A Expires December 1998 [Page 2] Internet-Draft Schedule MIB July 1998 MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 3. Overview The MIB defined in this memo provides scheduling of actions periodically or at specified dates and times. The actions can be used to realize on-duty / off-duty schedules or to trigger management functions in a DISMAN application. Schedules can be enabled or disabled by modifying a control object. This allows pre-configured schedules which are activated or de- activated by some other management functions. 3.1. Periodic Schedules Periodic schedules are based on fixed time periods between the initiation of scheduled actions. Periodic schedules are defined by specifying the number of seconds between two initiations. The time needed to complete the action is usually not known by the scheduler and does therefore not influence the next scheduling point. Implementations must guarantee that action invocations will not occur before their next scheduled time. However, implementations may be forced to delay invocations in the face of local constraints (e.g., a heavy load on higher-priority tasks). An accumulation of such delays would result in a drift of the scheduling interval with respect to time, and should be avoided. Scheduled actions collecting statistical data should retrieve time stamps from the data source and not rely on the accuracy of the periodic scheduler in order to obtain accurate statistics. 3.2. Calendar Schedules Calendar schedules trigger scheduled actions at specified dates and times. Calendar schedules are therefore aware of the notion of Expires December 1998 [Page 3] Internet-Draft Schedule MIB July 1998 months, days, weekdays, hours and minutes. It is possible to specify multiple values for each calendar item. This provides a mechanism for defining complex schedules. For example, a schedule could be defined which triggers an action every 15 minutes on a given weekday. 3.3. Actions Scheduled actions are modeled by SNMP set operations on local MIB variables. Scheduled actions described in this MIB are further restricted to objects of type INTEGER. This restriction does not limit the usefulness of the MIB. Simple schedules such as on-duty / off-duty schedules for resources that have a status MIB object (e.g. ifAdminStatus) are possible. More complex actions can be realized by triggering a management script which is responsible for performing complex state transitions. A management script can also be used to perform SNMP set operations on remote SNMP engines. Expires December 1998 [Page 4] Internet-Draft Schedule MIB July 1998 4. Definitions DISMAN-SCHEDULE-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Integer32, Unsigned32, Counter32, experimental FROM SNMPv2-SMI TEXTUAL-CONVENTION, DateAndTime, RowStatus, StorageType, VariablePointer FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB; schedMIB MODULE-IDENTITY LAST-UPDATED "9807170000Z" ORGANIZATION "IETF DISMAN Working Group" CONTACT-INFO "David B. Levi SNMP Research, Inc. 3001 Kimberlin Heights Road Knoxville, TN 37920-9716 U.S.A. Tel: +1 423 573 1434 E-mail: levi@snmp.com Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany Tel: +49-531-391-3283 E-mail: schoenw@ibr.cs.tu-bs.de" DESCRIPTION "This MIB module defines a MIB which provides mechanisms to schedule SNMP set operations periodically or at specific points in time." -- Get real registration number from IANA. -- ::= { mib-2 XXXX } ::= { experimental 6789 } -- Expires December 1998 [Page 5] Internet-Draft Schedule MIB July 1998 -- The various groups defined within this MIB definition: -- schedObjects OBJECT IDENTIFIER ::= { schedMIB 1 } schedNotifications OBJECT IDENTIFIER ::= { schedMIB 2 } schedConformance OBJECT IDENTIFIER ::= { schedMIB 3 } -- -- Textual Conventions: -- SnmpPduErrorStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This TC enumerates the SNMPv1 and SNMPv2 PDU error status codes as defined in RFC 1157 and RFC 1905. It also adds a pseudo error status code `noResponse' which indicates a timeout condition." SYNTAX INTEGER { noResponse(-1), noError(0), tooBig(1), noSuchName(2), badValue(3), readOnly(4), genErr(5), noAccess(6), wrongType(7), wrongLength(8), wrongEncoding(9), wrongValue(10), noCreation(11), inconsistentValue(12), resourceUnavailable(13), commitFailed(14), undoFailed(15), authorizationError(16), notWritable(17), inconsistentName(18) } -- -- The schedule table which controls the scheduler. -- schedTable OBJECT-TYPE SYNTAX SEQUENCE OF SchedEntry Expires December 1998 [Page 6] Internet-Draft Schedule MIB July 1998 MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table defines scheduled actions triggered by SNMP set operations." ::= { schedObjects 1 } schedEntry OBJECT-TYPE SYNTAX SchedEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular scheduled action." INDEX { schedOwner, schedName } ::= { schedTable 1 } SchedEntry ::= SEQUENCE { schedOwner SnmpAdminString, schedName SnmpAdminString, schedDescr SnmpAdminString, schedInterval Unsigned32, schedWeekDay BITS, schedMonth BITS, schedDay BITS, schedHour BITS, schedMinute BITS, schedContextName SnmpAdminString, schedVariable VariablePointer, schedValue Integer32, schedAdminStatus INTEGER, schedOperStatus INTEGER, schedFailures Counter32, schedLastFailure SnmpPduErrorStatus, schedLastFailed DateAndTime, schedStorageType StorageType, schedRowStatus RowStatus } schedOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The owner of this scheduling entry. The exact semantics of this string are subject to the security policy defined by the security administrator." ::= { schedEntry 1 } Expires December 1998 [Page 7] Internet-Draft Schedule MIB July 1998 schedName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The locally-unique, administratively assigned name for this scheduling entry. This object allows a schedOwner to have multiple entries in the schedTable." ::= { schedEntry 2 } schedDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The human readable description of the purpose of this scheduling entry." DEFVAL { ''H } ::= { schedEntry 3 } schedInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds between two action invocations of a periodic scheduler. Implementations must guarantee that action invocations will not occur before at least schedInterval seconds have passed. Implementations may be forced to delay invocations in the face of local constraints. A scheduled management function should therefore not rely on the accuracy provided by the scheduler implementation." ::= { schedEntry 4 } schedWeekDay OBJECT-TYPE SYNTAX BITS { sunday(0), monday(1), tuesday(2), wednesday(3), thursday(4), friday(5), saturday(6) } Expires December 1998 [Page 8] Internet-Draft Schedule MIB July 1998 MAX-ACCESS read-create STATUS current DESCRIPTION "The set of weekdays on which the scheduled action should take place." DEFVAL { {} } ::= { schedEntry 5 } schedMonth OBJECT-TYPE SYNTAX BITS { january(0), february(1), march(2), april(3), may(4), june(5), july(6), august(7), september(8), october(9), november(10), december(11) } MAX-ACCESS read-create STATUS current DESCRIPTION "The set of months during which the scheduled action should take place." DEFVAL { {} } ::= { schedEntry 6 } schedDay OBJECT-TYPE SYNTAX BITS { d0(0), d1(1), d2(2), d3(3), d4(4), d5(5), d6(6), d7(7), d8(8), d9(9), d10(10), d11(11), d12(12), d13(13), d14(14), d15(15), d16(16), d17(17), d18(18), d19(19), d20(20), d21(21), d22(22), d23(23), d24(24), d25(25), d26(26), d27(27), d28(28), d29(29), d30(30), d31(31) } MAX-ACCESS read-create STATUS current DESCRIPTION "The set of days in a month on which a scheduled action should take place. The first day of the month has the number d0(0)." Expires December 1998 [Page 9] Internet-Draft Schedule MIB July 1998 DEFVAL { {} } ::= { schedEntry 7 } schedHour OBJECT-TYPE SYNTAX BITS { h0(0), h1(1), h2(2), h3(3), h4(4), h5(5), h6(6), h7(7), h8(8), h9(9), h10(10), h11(11), h12(12), h13(13), h14(14), h15(15), h16(16), h17(17), h18(18), h19(19), h20(20), h21(21), h22(22), h23(23) } MAX-ACCESS read-create STATUS current DESCRIPTION "The set of hours within a day during which the scheduled action should take place." DEFVAL { {} } ::= { schedEntry 8 } schedMinute OBJECT-TYPE SYNTAX BITS { m0(0), m1(1), m2(2), m3(3), m4(4), m5(5), m6(6), m7(7), m8(8), m9(9), m10(10), m11(11), m12(12), m13(13), m14(14), m15(15), m16(16), m17(17), m18(18), m19(19), m20(20), m21(21), m22(22), m23(23), m24(24), m25(25), m26(26), m27(27), m28(28), m29(29), m30(30), m31(31), m32(32), m33(33), m34(34), m35(35), m36(36), m37(37), m38(38), m39(39), m40(40), m41(41), m42(42), m43(43), m44(44), m45(45), m46(46), m47(47), m48(48), m49(49), m50(50), m51(51), m52(52), m53(53), m54(54), m55(55), m56(56), m57(57), m58(58), m59(59) } MAX-ACCESS read-create STATUS current DESCRIPTION "The set of minutes within an hour when the scheduled action should take place." DEFVAL { {} } ::= { schedEntry 9 } schedContextName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION Expires December 1998 [Page 10] Internet-Draft Schedule MIB July 1998 "The context which contains the local MIB variable pointed to by schedVariable." ::= { schedEntry 10 } schedVariable OBJECT-TYPE SYNTAX VariablePointer MAX-ACCESS read-create STATUS current DESCRIPTION "An object identifier pointing to a local MIB variable which resolves to an ASN.1 primitive type of INTEGER." ::= { schedEntry 11 } schedValue OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The value which is written to the MIB object pointed to by schedVariable when the scheduler invokes an action. The implementation shall enforce the use of access control rules when performing the set operation on schedVariable. This is accomplished by calling the isAccessAllowed abstract service interface as defined in RFC 2271." ::= { schedEntry 12 } schedAdminStatus OBJECT-TYPE SYNTAX INTEGER { periodic(1), calendar(2), disabled(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The desired state of the schedule. The periodic(1) state indicates this entry specifies a periodic schedule. The calendar(2) state indicates that this entry describes a calendar schedule. The disabled(2) state indicates that this entry is currently inactive." DEFVAL { disabled } ::= { schedEntry 13 } schedOperStatus OBJECT-TYPE SYNTAX INTEGER { periodic(1), calendar(2), Expires December 1998 [Page 11] Internet-Draft Schedule MIB July 1998 disabled(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational state of this schedule. The periodic(1) state indicates that the periodic schedule is active and the calendar(2) state indicates that the calendar schedule is active. The disabled(3) state indicates that the schedule is currently not active." ::= { schedEntry 14 } schedFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This variable counts the number of failures while invoking the scheduled action." ::= { schedEntry 15 } schedLastFailure OBJECT-TYPE SYNTAX SnmpPduErrorStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The most recent error that occured during the invocation of a scheduled action. The value noError(0) is returned if no errors have occurred yet." DEFVAL { noError } ::= { schedEntry 16 } schedLastFailed OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time when the most recent failure occured. The value '0000000000000000'H is returned if no failure occured since the last re-initialization of the scheduler." DEFVAL { '0000000000000000'H } ::= { schedEntry 17 } schedStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current Expires December 1998 [Page 12] Internet-Draft Schedule MIB July 1998 DESCRIPTION "This object defines whether this scheduled action is kept in volatile storage and lost upon reboot or if this row is backed up by non-volatile or permanent storage. Conceptual rows having the value `permanent' must allow write access to the columnar objects schedDescr, schedInterval, schedContextName, schedVariable, schedValue, and schedAdminStatus. If an implementation supports the schedCalendarGroup, write access must be also allowed to the columnar objects schedWeekDay, schedMonth, schedDay, schedHour, schedMinute." DEFVAL { volatile } ::= { schedEntry 18 } schedRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this scheduled action. A control that allows entries to be added and removed from this table. The miminum number of objects that need to be set during row creation before a row can be set to `active' are schedContextName, schedVariable and schedValue." ::= { schedEntry 19 } -- -- Notifications that are emitted to indicate failures. The definition -- of schedMIBTraps makes notification registrations reversible. -- schedTraps OBJECT IDENTIFIER ::= { schedNotifications 0 } schedActionFailure NOTIFICATION-TYPE OBJECTS { schedLastFailure } STATUS current DESCRIPTION "This notification is generated whenever the invocation of a scheduled action fails." ::= { schedTraps 1 } -- conformance information schedCompliances OBJECT IDENTIFIER ::= { schedConformance 1 } schedGroups OBJECT IDENTIFIER ::= { schedConformance 2 } Expires December 1998 [Page 13] Internet-Draft Schedule MIB July 1998 -- compliance statements schedCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement the scheduling MIB." MODULE -- this module MANDATORY-GROUPS { schedGroup, schedNotificationsGroup } GROUP schedCalendarGroup DESCRIPTION "The schedCalendarGroup is mandatory only for those implementations that support calendar based schedules." OBJECT schedAdminStatus DESCRIPTION "The value calendar(2) is not valid for implementations that do no implement the schedCalendarGroup. Such an implementation must return inconsistentValue error responses for attempts to set schedAdminStatus to calendar(2)." ::= { schedCompliances 1 } schedGroup OBJECT-GROUP OBJECTS { schedDescr, schedInterval, schedContextName, schedVariable, schedValue, schedAdminStatus, schedOperStatus, schedFailures, schedLastFailure, schedLastFailed, schedStorageType, schedRowStatus } STATUS current DESCRIPTION "A collection of objects providing scheduling capabilities." ::= { schedGroups 1 } schedCalendarGroup OBJECT-GROUP OBJECTS { schedWeekDay, Expires December 1998 [Page 14] Internet-Draft Schedule MIB July 1998 schedMonth, schedDay, schedHour, schedMinute } STATUS current DESCRIPTION "A collection of objects providing calendar based schedules." ::= { schedGroups 2 } schedNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { schedActionFailure } STATUS current DESCRIPTION "The notifications emitted by the scheduler." ::= { schedGroups 3 } END Expires December 1998 [Page 15] Internet-Draft Schedule MIB July 1998 5. Usage Examples This section presents some examples how the scheduling MIB can be used to schedule scripts with the Script MIB [17] or to realize on- duty/off-duty schedules by modifying status objects of other MIB modules. 5.1. Starting a script to ping devices every 20 minutes It is assumed that the schedule entry is owned by schedOwner = "joe" and its name is schedName = "ping". The instance identifier for the scheduling entry is therefore 3.106.111.101.4.112.105.110.103. It is further assumed that the launch button entry is owned by smLaunchOwner = "joe" and its name is smLaunchName = "ping-devs". The complete object identifier for the launch button is therefore smLaunchStart.3.106.111.101.9.112.105.110.103.45.100.101.118.115. The script lives in the context identified by the string "engine1". The configuration of the scheduler entry which presses the launch button every 20 minutes would look as follows: schedInterval.3.106.111.101.4.112.105.110.103 = 1200 schedValue.3.106.111.101.4.112.105.110.103 = 0 schedContextName.3.106.111.101.4.112.105.110.103 = "engine1" schedVariable.3.106.111.101.4.112.105.110.103 = smLaunchStart.3.106.111.101.9.112.105.110.103.45.100.101.118.115 schedAdminStatus.3.106.111.101.4.112.105.110.103 = periodic(1) schedStorageType.3.106.111.101.4.112.105.110.103 = nonVolatile(3) schedRowStatus.3.106.111.101.4.112.105.110.103 = active(1) All the remaining columns in the schedTable represent status information and are not shown here. 5.2. Starting a script at midnight every Friday the 13th It is assumed that the schedule entry is owned by schedOwner = "joe" and its name is schedName = "13th". The instance identifier for the scheduling entry is therefore 3.106.111.101.4.49.51.116.104. It is further assumed that the launch button entry is owned by smLaunchOwner = "joe" and its name is smLaunchName = "ghost". The complete object identifier for the launch button is therefore Expires December 1998 [Page 16] Internet-Draft Schedule MIB July 1998 smLaunchStart.3.106.111.101.5.103.104.111.115.116. The script lives in the context identified by the string "engine1". The configuration of the scheduler entry which presses the launch button on every Friday 13th at midnight would look as follows: schedWeekDay.3.106.111.101.4.49.51.116.104 = { friday } schedMonth.3.106.111.101.4.49.51.116.104 = { january, february, march, april, may, june, july, august, september, october, november, december } schedDay.3.106.111.101.4.49.51.116.104 = { d13 } schedHour.3.106.111.101.4.49.51.116.104 = { h0 } schedMinute.3.106.111.101.4.49.51.116.104 = { m0 } schedValue.3.106.111.101.4.49.51.116.104 = 0 schedContextName.3.106.111.101.4.49.51.116.104 = "engine1" schedVariable.3.106.111.101.4.49.51.116.104 = smLaunchStart.3.106.111.101.5.103.104.111.115.116 schedAdminStatus.3.106.111.101.4.49.51.116.104 = calendar(2) schedStorageType.3.106.111.101.4.49.51.116.104 = nonVolatile(3) schedRowStatus.3.106.111.101.4.49.51.116.104 = active(1) All the remaining columns in the schedTable represent status information and are not shown here. 5.3. Turning an interface off during weekends This example assumes that a network interface should be taken down during weekends. The interface table (ifTable) of the IF-MIB [18] is assumed to exist in the context identified by an empty string and the index of the interface is ifIndex = 6. The scheduling entry which brings the interface down on every Friday evening at 20:30 (8:30 pm) is owned by schedOwner = "bob" and its name is schedName = "if-off". The instance identifier for the scheduling entry is therefore 3.98.111.98.6.105.102.45.111.102.102. schedWeekDay.3.98.111.98.6.105.102.45.111.102.102 = { monday } schedMonth.3.98.111.98.6.105.102.45.111.102.102 = { january, february, march, april, may, june, july, august, september, october, november, december } schedDay.3.98.111.98.6.105.102.45.111.102.102 = { d0, d1, d2, d3, d4, d5, d6, d7, d8, d9, Expires December 1998 [Page 17] Internet-Draft Schedule MIB July 1998 d10, d11, d12, d13, d14, d15, d16, d17, d18, d19, d20, d21, d22, d23, d24, d25, d26, d27, d28, d29, d30, d31 } schedHour.3.98.111.98.6.105.102.45.111.102.102 = { h20 } schedMinute.3.98.111.98.6.105.102.45.111.102.102 = { m30 } schedValue.3.98.111.98.6.105.102.45.111.102.102 = down(2) schedContextName.3.98.111.98.6.105.102.45.111.102.102 = "" schedVariable.3.98.111.98.6.105.102.45.111.102.102 = ifAdminStatus.6 schedAdminStatus.3.98.111.98.6.105.102.45.111.102.102 = calendar(2) schedStorageType.3.98.111.98.6.105.102.45.111.102.102 = nonVolatile(3) schedRowStatus.3.98.111.98.6.105.102.45.111.102.102 = active(1) The scheduling entry which brings the interface up on every Monday morning at 5:30 is owned by schedOwner = "bob" and its name is schedName = "if-on". The instance identifier for the scheduling entry is therefore 3.98.111.98.5.105.102.45.111.110. The entry in the schedTable which brings the interface up again on every Monday morning at 5:30 looks as follows: schedWeekDay.3.98.111.98.5.105.102.45.111.110 = { friday } schedMonth.3.98.111.98.5.105.102.45.111.110 = { january, february, march, april, may, june, july, august, september, october, november, december } schedDay.3.98.111.98.5.105.102.45.111.110 = { d0, d1, d2, d3, d4, d5, d6, d7, d8, d9, d10, d11, d12, d13, d14, d15, d16, d17, d18, d19, d20, d21, d22, d23, d24, d25, d26, d27, d28, d29, d30, d31 } schedHour.3.98.111.98.5.105.102.45.111.110 = { h5 } schedMinute.3.98.111.98.5.105.102.45.111.110 = { m30 } schedValue.3.98.111.98.5.105.102.45.111.110 = up(1) schedContextName.3.98.111.98.5.105.102.45.111.110 = "" schedVariable.3.98.111.98.5.105.102.45.111.110 = ifAdminStatus.6 schedAdminStatus.3.98.111.98.5.105.102.45.111.110 = calendar(2) schedStorageType.3.98.111.98.5.105.102.45.111.110 = nonVolatile(3) schedRowStatus.3.98.111.98.5.105.102.45.111.110 = active(1) Expires December 1998 [Page 18] Internet-Draft Schedule MIB July 1998 A similar configuration could be used to control other schedules. For example, one could change the "if-on" and "if-off" schedules to enable and disable the periodic scheduler defined in the first example. 6. Security Considerations Scheduled SNMP set operations must use the security credentials that were present when the corresponding row in the scheduling entry was created. An implementation must therefore record and maintain the credentials for every scheduling entry. An implementation must ensure that access control rules are applied when doing the set operation. This is accomplished by calling the isAccessAllowed abstract service interface defined in RFC 2271 [1]: 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 ) The securityModel, securityName and securityLevel parameters are set to the values that were recorded when the scheduling entry was created. The viewType parameter must select the write view and the contextName and variableName parameters are taken from the schedContextName and schedVariableName values of the scheduling entry. This MIB limits scheduled actions to objects in the local MIB. This avoids security problems with the delegation of access rights. However, it might be possible for a user of this MIB to own some schedules that might trigger far in the future. This can cause security risks if the security administrator did not properly update the access control lists when a user is withdrawn from an SNMP engine. Therefore, it is suggested that entries in the schedTable be cleaned up whenever a user is removed from an SNMP engine. To facilitate the provisioning of access control by a security administrator using the View-Based Access Control Model (VACM) defined in RFC 2275 [15] for tables in which multiple users may need to independently create or modify entries, the initial index is used Expires December 1998 [Page 19] Internet-Draft Schedule MIB July 1998 as an "owner index". Such an initial index has a syntax of SnmpAdminString, and can thus be trivially mapped to a securityName or groupName as defined in VACM, in accordance with a security policy. All entries in related tables belonging to a particular user will have the same value for this initial index. For a given user's entries in a particular table, the object identifiers for the information in these entries will have the same subidentifiers (except for the "column" subidentifier) up to the end of the encoded owner index. To configure VACM to permit access to this portion of the table, one would create vacmViewTreeFamilyTable entries with the value of vacmViewTreeFamilySubtree including the owner index portion, and vacmViewTreeFamilyMask "wildcarding" the column subidentifier. More elaborate configurations are possible. 7. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 8. Acknowledgments This document was produced by the IETF Distributed Management (DISMAN) working group. Expires December 1998 [Page 20] Internet-Draft Schedule MIB July 1998 9. References [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998 [2] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990 [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991 [4] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, Performance Systems International, March 1991 [5] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [6] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [7] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [8] 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. [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol Expires December 1998 [Page 21] Internet-Draft Schedule MIB July 1998 (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, SNMP Research, Inc., Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998. [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, IBM T. J. Watson Research, January 1998. [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2273, SNMP Research, Inc., Secure Computing Corporation, Cisco Systems, January 1998 [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, Inc., Cisco Systems, Inc., January 1998 [16] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [17] Levi, D., and J. Schoenwaelder, "Definitions of Managed Objects for the Delegation of Management Scripts", Internet-Draft , SNMP Research, Inc., TU Braunschweig, May 1998. [18] McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB using SMIv2", RFC 2233, Cisco Systems, FTP Software, November 1997. Expires December 1998 [Page 22] Internet-Draft Schedule MIB July 1998 10. Editors' Addresses David B. Levi Email: levi@snmp.com SNMP Research, Inc. Tel: +1 423 573 1434 3001 Kimberlin Heights Road Knoxville, TN 37920-9716 U.S.A. Juergen Schoenwaelder Email: schoenw@ibr.cs.tu-bs.de TU Braunschweig Tel: +49 531 391-3283 Bueltenweg 74/75 38106 Braunschweig Germany 11. Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires December 1998 [Page 23] Internet-Draft Schedule MIB July 1998 12. Revision History This section should be removed once this document gets published as an RFC. 12.1. Changes from o Clarifications about drifts between initiations of action in a periodic scheduler. o Made the registration of the notification reversible. o Changed the syntax of schedInterval from TimeInterval to Unsigned32. The maximum resolution is now seconds instead of hundreds of a second. o The conformance statement makes objects for the calendar-based scheduler optional. o Minor changes to make the MIB compile with smicng. 12.2. Changes from o Updated the section about the SNMP management framework and added references to SNMPv3. o Replaced Utf8String with SnmpAdminString. o Added Intellectual Property section. o Changed some wordings to make the text more readable. 12.3. Changes from o Fixes some typos. o Changed the semantics of "no bits set" and added DEFVALs which default to nothing scheduled. Expires December 1998 [Page 24] Internet-Draft Schedule MIB July 1998 o Added reference to BCP-11. o Added the schedContextName object to indicate the context of the variable being set by the scheduler. o Added three examples to demonstrate the usage of the scheduling MIB. o Created a new TC SnmpPduErrorStatus which contains SNMP PDU error status codes plus `noResponse'. o Added the new boilerplate and the references that go along with it. o Removed the transitional states `enabling' and `disabling' from the schedOperStatus object. o Defined the set of objects that must be writable if the storage type of a row is permanent. o List the objects that have to get values assigned during row creation in order to set a row to `active'. o Added text which describes how the isAccessAllowed abstract service interface is called for access control. o Added Randy's text which explains the indexing structure without refering to a DISMAN framework. o Replaced schedIndex with schedName. This allows semantic meaningful references to scheduling entries. 12.4. Changes from o Changed the MIB module name to DISMAN-SCHEDULE-MIB. o Fixed the example to make the indexing consistent with the new version of the Script MIB. o Removed the IMPLIED keyword and updated the examples. o Moved the change logs to the end of the document. Expires December 1998 [Page 25] Internet-Draft Schedule MIB July 1998 Table of Contents 1 Abstract ..................................................... 2 2 The SNMP Management Framework ................................ 2 3 Overview ..................................................... 3 3.1 Periodic Schedules ......................................... 3 3.2 Calendar Schedules ......................................... 3 3.3 Actions .................................................... 4 4 Definitions .................................................. 5 5 Usage Examples ............................................... 16 5.1 Starting a script to ping devices every 20 minutes ......... 16 5.2 Starting a script at midnight every Friday the 13th ........ 16 5.3 Turning an interface off during weekends ................... 17 6 Security Considerations ...................................... 19 7 Intellectual Property ........................................ 20 8 Acknowledgments .............................................. 20 9 References ................................................... 21 10 Editors' Addresses .......................................... 23 11 Full Copyright Statement .................................... 23 12 Revision History ............................................ 24 12.1 Changes from .......... 24 12.2 Changes from .......... 24 12.3 Changes from .......... 24 12.4 Changes from .......... 25 Expires December 1998 [Page 26] From maria@xedia.com Mon Jul 20 14:08:10 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 OAA18560 for ; Mon, 20 Jul 1998 14:08:09 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA19400 for ; Mon, 20 Jul 1998 14:07:20 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma019381; Mon, 20 Jul 98 14:07:13 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA10314 for ; Mon, 20 Jul 1998 14:06:37 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma009771; Mon, 20 Jul 98 14:06:09 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id OAA20101; Mon, 20 Jul 1998 14:06:40 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA27717 for ; Mon, 20 Jul 1998 12:06:32 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id OAA04788 for ; Mon, 20 Jul 1998 14:06:28 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma004773; Mon, 20 Jul 98 14:05:57 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id LAA21158 for ; Mon, 20 Jul 1998 11:44:04 -0400 (EDT) Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id OAA21831 for ; Mon, 20 Jul 1998 14:22:49 -0400 (EDT) Received: from henkell.ibr.cs.tu-bs.de (henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.1/8.9.0) with ESMTP id UAA01781; Mon, 20 Jul 1998 20:22:46 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id UAA04204; Mon, 20 Jul 1998 20:22:45 +0200 Date: Mon, 20 Jul 1998 20:22:45 +0200 Message-Id: <199807201822.UAA04204@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: internet-drafts@ietf.org CC: disman@nexen.com Subject: draft-ietf-disman-script-mib-05.txt Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Please post the attached document as Internet Draft . This document is created on behalf of the Distributed Management WG. Juergen Internet-Draft Script MIB July 1998 Definitions of Managed Objects for the Delegation of Management Scripts July 17, 1998 David B. Levi SNMP Research, Inc. levi@snmp.com Juergen Schoenwaelder TU Braunschweig schoenw@ibr.cs.tu-bs.de 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 ``work in progress.'' To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Please send comments to the Distributed Management Working Group, . Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Expires December 1998 [Page 1] Internet-Draft Script MIB July 1998 1. 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 a set of managed objects that allow the delegation of management scripts to distributed managers. This memo does not specify a standard for the Internet community. 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2271 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in RFC 1155 [2], RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC 1904 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2273 [14] and the view-based access control mechanism described in RFC 2275 [15]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A Expires December 1998 [Page 2] Internet-Draft Script MIB July 1998 MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 3. Overview The Script MIB module defined in this memo can be used to delegate management functions to distributed managers. Management functions are defined as management scripts written in a management scripting language. This MIB makes no assumptions about the language itself and even allows distribution of compiled native code, if an implementation is able to execute native code under the control of this MIB. The Script MIB defines a standard interface for the delegation of management functions based on the Internet management framework. In particular, it provides the following capabilities: 1. Capabilities to transfer management scripts to a distributed manager. 2. Capabilities for initiating, suspending, resuming and terminating management scripts. 3. Capabilities to transfer arguments for management scripts. 4. Capabilities to monitor and control running management scripts. 5. Capabilities to transfer the results produced by running management scripts. This memo does not address any additional topics like the generation of notifications or how to address remote agents from a Script MIB implementation. 3.1. Terms This section defines the terms used throughout this memo. Expires December 1998 [Page 3] Internet-Draft Script MIB July 1998 o A `distributed manager' is a processing entity which is capable of performing network management functions. For the scope of this memo, a distributed manager is assumed to implement the Script MIB. o A `higher-level manager', or just `manager', is a processing entity or human who initiates and controls the operations performed by one or more distributed managers. o A `management script' is a set of instructions written in an executable language which implements a management function. o A `management scripting language' is a language used to write management scripts. Note, that the term scripting language does not imply that the language must have the characteristics of scripting languages. o A `distributed manager' can be decomposed into an `SNMP entity' which implements the Script MIB defined in this memo and the `runtime system' that executes scripts. The Script MIB sees the runtime system as the managed resource which is controlled by the MIB. The runtime system can act as an SNMP application, according to the SNMP architecture defined in RFC 2271 [1]. For example, a runtime system which sends SNMP requests to other SNMP entities will act as a command generator application. The SNMP applications in the runtime system may use the same SNMP engine which also serves the command responder application used to implement the Script MIB, but they are not required to do so. 4. Requirements and Design Issues This section discusses some general requirements that have influenced the design of the Script MIB. o The Script MIB must not make any assumptions about specific languages or runtime systems. o The Script MIB must provide mechanisms that help to avoid new management problems (e.g. script version problems). o The Script MIB must provide SNMP interfaces to all functions required to delegate management scripts. However, other protocols might be used in addition if they provide a significant improvement in terms of convenience for Expires December 1998 [Page 4] Internet-Draft Script MIB July 1998 implementation or performance. o The Script MIB must be organized so that access can be controlled effectively by using view-based access control [15]. The following sections discuss some design issues in more detail. 4.1. Script Languages The Script MIB defined in this memo makes no assumption about the script language. This MIB can therefore be used in combination with different languages (such as Tcl or Java) and/or different versions of the same language. No assumptions are made about the format in which management scripts are transferred. The Script MIB provides access to information about the language versions supported by a Script MIB implementation so that a manager can learn about the capabilities provided by an implementation. Languages and language versions are identified as follows: 1. The language is identified by an object identifier. Object identifier for well-known languages will be registered by the Internet Assigned Numbers Authority (IANA). Enterprise specific languages can also be registered in the enterprise specific OID subtree. 2. A particular version of a language is identified by a language version number. The combination of a language object identifier and a language version is in most cases sufficient to decide whether a script can be executed or not. 3. Different implementations of the same language version might have differences due to ambiguities in the language definition or additional language features provided by an implementor. An additional object identifier value is provided which identifies the organization which provides the implementation of a language. This might be used by scripts that require a particular implementation of a language. 4. Finally, there might be different versions of a language implementation. A version number for the language implementation is provided so that the manager can also distinguish between different implementations from the same organization of a particular language version. The version numbers can either be used by a manager to select the Expires December 1998 [Page 5] Internet-Draft Script MIB July 1998 language version required to execute a particular script or to select a script that fits the language versions supported by a particular Script MIB implementation. An additional table lists language extensions that provide features not provided by the core language. Language extensions are usually required to turn a general purpose language into a management language. In many cases, language extensions will come in the form of libraries that provide capabilities like sending SNMP requests to remote SNMP agents or accessing the local MIB instrumentation. Every extension is associated with a language and carries its own version numbers. 4.2. Script Transfer There are two different ways to transfer management scripts to a distributed manager. The first approach requires that the manager pushes the script to the distributed manager. This is therefore called the `push model'. The second approach is the `pull model' where the manager tells the distributed manager the location of the script and the distributed manager retrieves the script itself. The MIB defined in this memo supports both models. The `push model' is realized by a table which allows a manager to write scripts by sending a sequence of SNMP set requests. The script can be split into several fragments in order to deal with SNMP message size limitations. The `pull model' is realized by the use of Uniform Resource Locators (URLs) [17] that point to the script source. The manager writes the URL which points to the script source to the distributed manager by sending an SNMP set request. The distributed manager is then responsible for retrieving the document using the protocol specified in the URL. This allows the use of protocols like FTP [18] or HTTP [19] to transfer large management scripts efficiently. The Script MIB also allows management scripts that are hard-wired into the Script MIB implementation. Built-in scripts can either be implemented in a language runtime system, or they can be built natively into the Script MIB implementation. The implementation of the `push model' or the `pull model' is not required. Scripts can be stored in non-volatile storage. This allows a distributed manager to restart scripts if it is restarted (off-line restart). A manager is not required to push scripts back into the distributed manager after a restart if the script is backed up in Expires December 1998 [Page 6] Internet-Draft Script MIB July 1998 non-volatile storage. Every script is identified by an administratively assigned name. This name may be used to derive the name which is used to access the script in non-volatile storage. This mapping is implementation specific. However, the mapping must ensure that the Script MIB implementation can handle scripts with the same administrative name owned by different managers. One way to achieve this is to use the script owner in addition to the script name in order to derive the internal name used to refer to a particular script in non-volatile storage. 4.3. Script Execution The Script MIB permits execution of several instances of the same or different management scripts. Script arguments are passed as OCTET STRING values. Scripts return a single result value which is also an OCTET STRING value. The semantic interpretation of result values is left to the invoking manager or other management scripts. There is necessarily an agreement between the script invoker and the script itself about the format and the semantics of the arguments and the results. Scripts can also export complex results through a MIB interface. This allows a management application to access and use script results in the same manner as it processes any other MIB data. However, the Script MIB does not provide any special support for the implementation of MIBs through scripts. Runtime errors terminate active scripts. An exit code is left in the MIB and error specific information is stored as the result value. A notification is generated when a script terminates with an error exit code. Script arguments and results do not have any size limitations other than the limits imposed by the SMI and the SNMP protocol. However, implementations of this MIB might have further restrictions. A script designer might therefore choose to return the results via other mechanisms if the script results can be very large. One possibility is to return a URL as a script result which points to the file containing the script output. Executing scripts have a status object attached which allows script execution to be suspended, resumed, or aborted. The precise semantics of the suspend and resume operations are language and runtime system dependent. Some runtime systems may choose to not Expires December 1998 [Page 7] Internet-Draft Script MIB July 1998 implement the suspend/resume operations. A history of finished scripts is kept in the MIB. A script invoker can collect results at a later point in time (offline operation). Control objects can be used to control how entries in the history are aged out if the table fills up. 5. The Structure of the MIB This section presents the structure of the MIB. The objects are arranged into the following groups: o language group (smLanguageGroup) o script group (smScriptGroup) o script code group (smCodeGroup) o script launch group (smLaunchGroup) o running script group (smRunGroup) 5.1. The smLanguageGroup The smLanguageGroup is used to provide information about the languages and the language extensions supported by a Script MIB implementation. This group includes two tables. The smLangTable lists all languages supported by a Script MIB implementation and the smExtsnTable lists the extensions that are available for a given language. 5.2. The smScriptGroup The smScriptGroup consists of a single table, called the smScriptTable. The smScriptTable lists all scripts known to a Script MIB implementation. The smScriptTable contains objects that allow the following operations: o download scripts from a URL (pull model) o read scripts from local non-volatile storage o store scripts in local non-volatile storage Expires December 1998 [Page 8] Internet-Draft Script MIB July 1998 o delete scripts from local non-volatile storage o list permanent scripts (that can not be changed or removed) o read and modify the script status (enabled, disabled, editing) A status object called smScriptOperStatus allows a manager to obtain the current status of a script. It is also used to provide an error indication if an attempt to invoke one of the operations listed above fails. The status change of a script can be requested by modifying the associated smScriptAdminStatus object. The source of a script is defined by the smScriptSource object. This object may contain a URL pointing to a remote location which provides access to the management script. The script source is read from the smCodeTable (described below) or from non-volatile storage if the smScriptSource object contains an empty URL. The smScriptStorageType object is used to distinguish between scripts read from non-volatile storage and scripts read from the smCodeTable. Scripts are automatically loaded once the smScriptAdminStatus object is set to `enabled'. Loading a script includes retrieving the script (probably from a remote location), compiling the script for languages that require a compilation step, and making the code available to the runtime system. The smScriptOperStatus object is used to indicate the status of the loading process. This object will start in the state `retrieving', switch to the state `compiling' and finally reach the state `enabled'. Errors during the retrieval or compilation phase will result in an error state such as `compilationFailed'. 5.3. The smCodeGroup The smCodeGroup consists of a single table, called the smCodeTable, which provides the ability to transfer and modify scripts via SNMP set requests. In particular, the smCodeTable allows the following operations: o download scripts via SNMP (push model) o modify scripts via SNMP (editing) The smCodeTable lists the code of a script. A script can be fragmented over multiple rows of the smCodeTable in order to handle SNMP message size limitations. Modifications of the smCodeTable are only possible if the associated smScriptOperStatus object has the value `editing'. The Script MIB implementation reloads the modified Expires December 1998 [Page 9] Internet-Draft Script MIB July 1998 script code once the smScriptOperStatus changes to `enabled' again. The implementation of the smCodeGroup is optional. 5.4. The smLaunchGroup The smLaunchGroup contains a single table, the smLaunchTable. The smLaunchTable allows the following operations: o associate a script with an owner used during script execution o provide arguments and parameters for script invocation o invoke scripts with a single set operation The smLaunchTable describes scripts and their parameters that are ready to be launched. An entry in the smLaunchTable attaches an argument to a script and control values which, for example, define the maximum number of times that a script invoked from a particular row in the smLaunchTable may be running concurrently. An entry in the smLaunchTable also defines the owner which will be used to associate permissions with the script execution. 5.5. The smRunGroup The smRunGroup contains a single table, called the smRunTable, which lists all scripts that are currently running or have terminated recently. The smRunTable contains objects that allow the following operations: o retrieve status information from running scripts o control running scripts (suspend, resume, abort) o retrieve results from recently terminated scripts o control the remaining maximum lifetime of a running script o control how long script results are accessible Every row in the smRunTable contains the argument passed during script invocation, the result produced by the script and the script exit code. The smRunTable also provides information about the current run state as well as start and end time-stamps. There are Expires December 1998 [Page 10] Internet-Draft Script MIB July 1998 three writable objects in the smRunTable. The smRunLifeTime object defines the maximum time a running script may run before it is terminated by the Script MIB implementation. The smRunExpireTime object defines the time that a completed script can stay in the smRunTable before it is aged out. The smRunControl object allows running scripts to be suspended, resumed, or aborted. Expires December 1998 [Page 11] Internet-Draft Script MIB July 1998 6. Definitions DISMAN-SCRIPT-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Integer32, Unsigned32, experimental FROM SNMPv2-SMI RowStatus, TimeInterval, DateAndTime, StorageType, DisplayString FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB; scriptMIB MODULE-IDENTITY LAST-UPDATED "9807170000Z" ORGANIZATION "IETF DISMAN Working Group" CONTACT-INFO "David B. Levi SNMP Research, Inc. 3001 Kimberlin Heights Road Knoxville, TN 37920-9716 U.S.A. Tel: +1 423 573 1434 E-mail: levi@snmp.com Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany Tel: +49-531-391-3283 E-mail: schoenw@ibr.cs.tu-bs.de" DESCRIPTION "This MIB module defines a set of objects that allow to delegate management scripts to distributed managers." -- XXX Replace with real registration number from IANA. Note, the -- XXX IMPORTS must be updated when the real number is assigned. ::= { experimental 5678 } -- -- The groups defined within this MIB module: -- Expires December 1998 [Page 12] Internet-Draft Script MIB July 1998 smObjects OBJECT IDENTIFIER ::= { scriptMIB 1 } smNotifications OBJECT IDENTIFIER ::= { scriptMIB 2 } smConformance OBJECT IDENTIFIER ::= { scriptMIB 3 } -- -- Script language and language extensions. -- -- This group defines tables which list the languages and the -- language extensions supported by a script MIB implementation. -- Languages are uniquely identified by object identifier values. -- smLangTable OBJECT-TYPE SYNTAX SEQUENCE OF SmLangEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists supported script languages." ::= { smObjects 1 } smLangEntry OBJECT-TYPE SYNTAX SmLangEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular language." INDEX { smLangIndex } ::= { smLangTable 1 } SmLangEntry ::= SEQUENCE { smLangIndex Unsigned32, smLangLanguage OBJECT IDENTIFIER, smLangVersion SnmpAdminString, smLangVendor OBJECT IDENTIFIER, smLangRevision SnmpAdminString, smLangDescr SnmpAdminString } smLangIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The locally arbitrary, but unique identifier associated with this language entry. The value is expected to remain constant at least from one Expires December 1998 [Page 13] Internet-Draft Script MIB July 1998 re-initialization of the entity's network management system to the next re-initialization." ::= { smLangEntry 1 } smLangLanguage OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The globally unique identification of the language." ::= { smLangEntry 2 } smLangVersion OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The version number of the language. It is suggested that the version number consist of one or more decimal numbers separated by dots, where the first number is called the major version number." ::= { smLangEntry 3 } smLangVendor OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "An object identifer which identifies the vendor who provides the implementation of the language. This object identifer should point to the OID node directly below the enterprise OID {1 3 6 1 4 1} allocated for the vendor. The value must by the object identifier {0 0} if the vendor is not known." ::= { smLangEntry 4 } smLangRevision OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The version number of the language implementation. The value of this object must be an empty string if version number of the implementation is unknown. It is suggested that the value consist of one or more Expires December 1998 [Page 14] Internet-Draft Script MIB July 1998 decimal numbers separated by dots, where the first number is called the major version number." ::= { smLangEntry 5 } smLangDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A textual description of the language." ::= { smLangEntry 6 } smExtsnTable OBJECT-TYPE SYNTAX SEQUENCE OF SmExtsnEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists supported language extensions." ::= { smObjects 2 } smExtsnEntry OBJECT-TYPE SYNTAX SmExtsnEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular language extension." INDEX { smLangIndex, smExtsnIndex } ::= { smExtsnTable 1 } SmExtsnEntry ::= SEQUENCE { smExtsnIndex Unsigned32, smExtsnExtension OBJECT IDENTIFIER, smExtsnVersion SnmpAdminString, smExtsnVendor OBJECT IDENTIFIER, smExtsnRevision SnmpAdminString, smExtsnDescr SnmpAdminString } smExtsnIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The locally arbitrary, but unique identifier associated with this language extension entry. Expires December 1998 [Page 15] Internet-Draft Script MIB July 1998 The value is expected to remain constant at least from one re-initialization of the entity's network management system to the next re-initialization." ::= { smExtsnEntry 1} smExtsnExtension OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The globally unique identification of the language extension." ::= { smExtsnEntry 2 } smExtsnVersion OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The version number of the language extension. It is suggested that the version number consist of one or more decimal numbers separated by dots, where the first number is called the major version number." ::= { smExtsnEntry 3 } smExtsnVendor OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "An object identifer which identifies the vendor who provides the implementation of the extension. The object identifer value should point to the OID node directly below the enterprise OID {1 3 6 1 4 1} allocated for the vendor. The value must by the object identifier {0 0} if the vendor is not known." ::= { smExtsnEntry 4 } smExtsnRevision OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The version number of the extension implementation. The value of this object must be an empty string if version number of the implementation is unknown. Expires December 1998 [Page 16] Internet-Draft Script MIB July 1998 It is suggested that the value consist of one or more decimal numbers separated by dots, where the first number is called the major version number." ::= { smExtsnEntry 5 } smExtsnDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A textual description of the language extension." ::= { smExtsnEntry 6 } -- -- Scripts known by the Script MIB implementation. -- -- This group defines a table which lists all known scripts. -- Scripts can be added and removed through manipulation of the -- smScriptTable. -- smScriptObjects OBJECT IDENTIFIER ::= { smObjects 3 } smScriptTable OBJECT-TYPE SYNTAX SEQUENCE OF SmScriptEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists and describes locally known scripts." ::= { smScriptObjects 1 } smScriptEntry OBJECT-TYPE SYNTAX SmScriptEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular script. Every script that is stored in non-volatile memory is required to appear in this script table." INDEX { smScriptOwner, smScriptName } ::= { smScriptTable 1 } SmScriptEntry ::= SEQUENCE { smScriptOwner SnmpAdminString, smScriptName SnmpAdminString, smScriptDescr SnmpAdminString, Expires December 1998 [Page 17] Internet-Draft Script MIB July 1998 smScriptLanguage Integer32, smScriptSource DisplayString, smScriptAdminStatus INTEGER, smScriptOperStatus INTEGER, smScriptStorageType StorageType, smScriptRowStatus RowStatus } smScriptOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The manager who owns this row in the smScriptTable." ::= { smScriptEntry 1 } smScriptName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS not-accessible STATUS current DESCRIPTION "The locally-unique, administratively assigned name for this script. This object allows an smScriptOwner to have multiple entries in the smScriptTable. This value of this object may be used to derive the name (e.g. a file name) which is used by the Script MIB implementation to access the script in non-volatile storage. The details of this mapping are implementation specific. However, the mapping needs to ensure that scripts created by different owners with the same script name do not map to the same name in non-volatile storage." ::= { smScriptEntry 2 } smScriptDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "A description of the purpose of the script." ::= { smScriptEntry 3 } smScriptLanguage OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION Expires December 1998 [Page 18] Internet-Draft Script MIB July 1998 "The value of this object type identifies an entry in the smLangTable which is used to execute this script. The special value 0 may be used by hard-wired scripts that can not be modified and that are executed by internal functions." ::= { smScriptEntry 4 } smScriptSource OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "This object either contains a reference to the script source or an empty string. A reference must be given in the form of a Uniform Resource Locator (URL) as defined in RFC 1738. The allowed character sets and the encoding rules defined in RFC 1738 section 2.2 apply. The Script MIB implementation will `pull' the script source from the URL contained in this object if the URL is not empty. An empty URL indicates that the script source is loaded from local storage. The source is read from the smCodeTable if the value of smScriptStorageType is volatile. Otherwise, the source is read from non-volatile storage. Note that there is a difference between a URL which usues the file scheme defined in RFC 1738 section 3.10 and an empty URL. The file URL scheme points to a named file on the system running the Script MIB implementation while the empty URL refers to a script by smScriptName and smScriptOwner. An implementation might map this logical name to whatever name is appropriate to access the script source in non-volatile storage. The following changes to smScriptSource require special attention: - Empty value changes to empty value: This has no effect. - Empty value changes to non-empty value: This destroys the local script (possibly deleting it from non-volatile storage), and initiates a download of the script source the specified location. - Non-empty value changes to empty value: If the smScriptStorageType is non-volatile, the Expires December 1998 [Page 19] Internet-Draft Script MIB July 1998 currently loaded script is written to non-volatile storage. Otherwise, no effect. - Non-empty value changes to non-empty value: This initiates a download of the script from the specified location. Set requests to change this object are only valid if the value of smScriptOperStatus is `disabled'." DEFVAL { ''H } ::= { smScriptEntry 5 } smScriptAdminStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2), editing(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object indicates the desired status of the script. See the definition of smScriptOperStatus for a description of the values." DEFVAL { disabled } ::= { smScriptEntry 6 } smScriptOperStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2), editing(3), retrieving(4), compiling(5), noSuchScript(6), accessDenied(7), wrongLanguage(8), wrongVersion(9), compilationFailed(10), noResourcesLeft(11), unknownProtocol(12), protocolFailure(13), genericError(14) } MAX-ACCESS read-only STATUS current DESCRIPTION "The actual status of the script in the runtime system. The Expires December 1998 [Page 20] Internet-Draft Script MIB July 1998 value of this object is only meaningful when the value of the smScriptRowStatus object is `active'. The smScriptOperStatus object may have the following values: - `enabled' indicates that the script is available and can be started by a launch table entry. - `disabled' indicates that the script can not be used. - `editing' indicates that the script can be modified in the smCodeTable. - `retrieving' indicates that the script is currently being loaded from non-volatile storage or a remote system. - `compiling' indicates that the script is currently being compiled by the runtime system. - `noSuchScript' indicates that the script does not exist at the smScriptSource. - `accessDenied' indicates that the script can not be loaded from the smScriptSource due to a lack of permissions. - `wrongLanguage' indicates that the script can not be loaded from the smScriptSource because of a language mismatch. - `wrongVersion' indicates that the script can not be loaded from the smScriptSource because of a language version mismatch. - `compilationFailed' indicates that the compilation failed. - `noResourcesLeft' indicates that the runtime system does not have enough resources to load the script. - `unknownProtocol' indicates that the script could not be loaded from the smScriptSource because the requested protocol is not supported. - `protocolFailure' indicates that the script could not be loaded from the smScriptSource because of a protocol failure. - `genericError' indicates that the script could not be loaded due to an error condition not listed above. Expires December 1998 [Page 21] Internet-Draft Script MIB July 1998 The `retrieving' and `compiling' states are transient states which will either lead to one of the error states or the `enabled' state. The `disabled' and `editing' states are administrative states which are only reached by explicit management operations. The implementation has to ensure that all launch table entries which refer to this script entry have a smLaunchOperStatus value of `disabled' when the value of this object is not `enabled'." DEFVAL { disabled } ::= { smScriptEntry 7 } smScriptStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines whether this row and the script controlled by this row are kept in volatile storage and lost upon reboot or if this row is backed up by non-volatile or permanent storage. Setting this object to `nonVolatile' stores the script controlled by this row into non-volatile storage. Setting this object to volatile removes a script from non-volatile storage if the script has been in non-volatile storage before. Attempts to set this object to permanent will always fail with an inconsistentValue error. The agent has to make sure that scripts controlled by a row where smScriptStorageType is `nonVolatile' or permanent are loaded at agent startup time. The value of smScriptStorageType is only meaningful if the value of the corresponding RowStatus object is `active'. If smScriptStorageType has the value permanent(4), then all objects whose MAX-ACCESS value is read-create must be writable, with the exception of the smScriptStorageType and smScriptRowStatus objects, which should be only be readable." DEFVAL { volatile } ::= { smScriptEntry 8 } smScriptRowStatus OBJECT-TYPE SYNTAX RowStatus Expires December 1998 [Page 22] Internet-Draft Script MIB July 1998 MAX-ACCESS read-create STATUS current DESCRIPTION "A control that allows entries to be added and removed from this table. Changing the smScriptRowStatus from `active' to `notInService' will remove the associated script from the runtime system. The value of smScriptOperStatus will be reset to `disabled'. Deleting conceptual rows from this table includes the deletion of all resources associated with this row. This implies that a script is removed from non-volatile storage if the value of smScriptStorageType is non-volatile. An entry may not exist in the `active' state unless all required objects in the entry have appropriate values. Rows that are not complete or not in service are not known by the script runtime system. Attempts to `destroy' a row or to set a row `notInService' while the script is executing will result in an inconsistentValue error. Attempts to `destroy' a row or to set a row `notInService' where the value of the smScriptStorageType object is `permanent' or `readOnly' will result in an inconsistentValue error." ::= { smScriptEntry 9 } -- -- Access to script code via SNMP -- -- The smCodeTable allows script code to be read and modified -- via SNMP. -- smCodeTable OBJECT-TYPE SYNTAX SEQUENCE OF SmCodeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the script code for scripts that are retrieved or written via SNMP." ::= { smScriptObjects 2 } Expires December 1998 [Page 23] Internet-Draft Script MIB July 1998 smCodeEntry OBJECT-TYPE SYNTAX SmCodeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular fragment of a script." INDEX { smScriptOwner, smScriptName, smCodeIndex } ::= { smCodeTable 1 } SmCodeEntry ::= SEQUENCE { smCodeIndex Unsigned32, smCodeText OCTET STRING, smCodeRowStatus RowStatus } smCodeIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index value identifying this code fragment." ::= { smCodeEntry 1 } smCodeText OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..1024)) MAX-ACCESS read-create STATUS current DESCRIPTION "The code that makes up a fragment of the script." ::= { smCodeEntry 2 } smCodeRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "A control that allows entries to be added and removed from this table." ::= { smCodeEntry 3 } -- -- Script execution. -- -- This group defines tables which allow script execution to be -- initiated, suspended, resumed, and terminated. It also provides -- a mechanism for keeping a history of recent script executions -- and their results. Expires December 1998 [Page 24] Internet-Draft Script MIB July 1998 -- smRunObjects OBJECT IDENTIFIER ::= { smObjects 4 } smLaunchTable OBJECT-TYPE SYNTAX SEQUENCE OF SmLaunchEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists and describes scripts that are ready to be executed together with their parameters." ::= { smRunObjects 1 } smLaunchEntry OBJECT-TYPE SYNTAX SmLaunchEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular executable script." INDEX { smLaunchOwner, smLaunchName } ::= { smLaunchTable 1 } SmLaunchEntry ::= SEQUENCE { smLaunchOwner SnmpAdminString, smLaunchName SnmpAdminString, smLaunchScriptOwner SnmpAdminString, smLaunchScriptName SnmpAdminString, smLaunchArgument OCTET STRING, smLaunchMaxRunning Unsigned32, smLaunchMaxCompleted Unsigned32, smLaunchLifeTime TimeInterval, smLaunchExpireTime TimeInterval, smLaunchStart Integer32, smLaunchControl INTEGER, smLaunchAdminStatus INTEGER, smLaunchOperStatus INTEGER, smLaunchRunIndexNext Unsigned32, smLaunchStorageType StorageType, smLaunchRowStatus RowStatus } smLaunchOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The manager who owns this row in the smLaunchTable." Expires December 1998 [Page 25] Internet-Draft Script MIB July 1998 ::= { smLaunchEntry 1 } smLaunchName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The locally-unique, administratively assigned name for this launch button. This object allows an smLaunchOwner to have multiple entries in the smLaunchTable." ::= { smLaunchEntry 2 } smLaunchScriptOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object in combination with the value of smLaunchScriptName identifies the script that can be launched from this smLaunchTable entry. Attempts to write this objects will fail with an inconsistentValue error if the value of smLaunchOperStatus is `enabled'." ::= { smLaunchEntry 3 } smLaunchScriptName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object in combination with the value of the smLaunchScriptOwner identifies the script that can be launched from this smLaunchTable entry. Attempts to write this objects will fail with an inconsistentValue error if the value of smLaunchOperStatus is `enabled'." ::= { smLaunchEntry 4 } smLaunchArgument OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-create STATUS current DESCRIPTION "The argument supplied to the script. When a script is invoked, the value of this object is used to initialize the smRunArgument object." DEFVAL { ''H } ::= { smLaunchEntry 5 } Expires December 1998 [Page 26] Internet-Draft Script MIB July 1998 smLaunchMaxRunning OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of concurrently running scripts that may be invoked from this entry in the smLaunchTable." DEFVAL { 1 } ::= { smLaunchEntry 6 } smLaunchMaxCompleted OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of finished scripts invoked from this entry in the smLaunchTable allowed to be retained in the smRunTable. The value of this object is checked whenever a script terminates. Entries in the smRunTable are deleted until the number of completed scripts is smaller than the value of this object. Scripts whose smRunEndTime value indicates the oldest completion time are deleted first." DEFVAL { 1 } ::= { smLaunchEntry 7 } smLaunchLifeTime OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-create STATUS current DESCRIPTION "The default maximum amount of time a script launched from this entry may run. The value of this object is used to initialize the smRunLifeTime object when a script is launched. Changing the value of an smLaunchLifeTime instance does not affect scripts previously launched from this entry." DEFVAL { 360000 } ::= { smLaunchEntry 8 } smLaunchExpireTime OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-create STATUS current DESCRIPTION "The default maximum amount of time information about a script launched from this entry is kept in the smRunTable after the script has completed execution. The value of Expires December 1998 [Page 27] Internet-Draft Script MIB July 1998 this object is used to initialize the smRunExpireTime object when a script is launched. Changing the value of an smLaunchExpireTime instance does not affect scripts previously launched from this entry." DEFVAL { 360000 } ::= { smLaunchEntry 9 } smLaunchStart OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to start the execution of scripts. When retrieved, the value will be the value of smRunIndex for the last script that started execution by manipulating this object. The value will be zero if no script started execution yet. A script is started by setting this object to an unused smRunIndex value. A new row in the smRunTable will be created which is indexed by the value supplied by the set-request in addition to the value of smLaunchOwner and smLaunchName. An unused value can be obtained by reading the smLaunchRunIndexNext object. Setting this object to the special value 0 will start the script with a self-generated smRunIndex value. The consequence is that the script invoker has no reliable way to determine the smRunIndex value for this script invocation and that the invoker has therefore no way to obtain the results from this script invocation. The special value 0 is however useful for scheduled script invocations. Setting this object requires to perform the following checks: 1) The value of the smLaunchOperStatus object in this entry of the smLaunchTable must be `enabled'. 2) The values contents of smLaunchOwner and smLaunchName of this row must identify an existing entry in the smScriptTable. 3) The value of smScriptOperStatus of this entry must be `enabled'. 4) The principal performing the set operation must have read access to the script. This must be checked by calling the isAccessAllowed abstract service interface Expires December 1998 [Page 28] Internet-Draft Script MIB July 1998 defined in RFC 2271 on the row in the smScriptTable identified by smLaunchOwner and smLaunchName. The isAccessAllowed abstract service interface must be called on all columnar objects in the smScriptTable with a MAX-ACCESS value different than `not-accessible'. The test fails as soon as a call indicates that access is not allowed. 5) If the value provided by the set operation is not 0, a check must be made that the value is currently not in use. Otherwise, a suitable unused value must be generated. 6) The number of currently executing scripts invoked from this smLaunchTable entry must be less than smLaunchMaxRunning. Attempts to start a script will fail with an inconsistentValue error if one of the checks described above fails. Otherwise, if all checks have been passed, a new entry in the smRunTable will be created indexed by smLaunchOwner, smLaunchName and the new value for smRunIndex. The value of smLaunchArgument will be copied into smRunArgument, the value of smLaunchLifeTime will be copied to smRunLifeTime, and the value of smLaunchExpireTime will be copied to smRunExpireTime. The smRunStartTime will be set to the current time and the smRunState will be set to `initializing' before the script execution is initiated in the appropriate runtime system." DEFVAL { 0 } ::= { smLaunchEntry 10 } smLaunchControl OBJECT-TYPE SYNTAX INTEGER { abort(1), suspend(2), resume(3), nop(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to request a state change for all running scripts in the smRunTable that were started from this row in the smLaunchTable. Expires December 1998 [Page 29] Internet-Draft Script MIB July 1998 Setting this object to abort(1), suspend(2) or resume(3) will set the smRunControl object of all applicable rows in the smRunTable to abort(1), suspend(2) or resume(3) respectively. The phrase `applicable rows' means the set of rows which were created from this entry in the smLaunchTable and whose value of smRunState allows the corresponding state change as described in the definition of the smRunControl object. Setting this object to nop(4) will always succeed and has no effect." DEFVAL { nop } ::= { smLaunchEntry 11 } smLaunchAdminStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object indicates the desired status of this launch table entry." DEFVAL { disabled } ::= { smLaunchEntry 12 } smLaunchOperStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object indicates the actual status of this launch table entry. An `enabled' launch table entry can be used to start scripts while a `disabled' launch table entry will refuse any attempts to start scripts. The value `enabled' requires that the smLaunchRowStatus object is active. The value `disabled' requires that there are no entries in the smRunTable associated with this smLaunchTable entry." DEFVAL { disabled } ::= { smLaunchEntry 13 } smLaunchRunIndexNext OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only Expires December 1998 [Page 30] Internet-Draft Script MIB July 1998 STATUS current DESCRIPTION "This variable is used for creating rows in the smRunTable. The value of this variable is a currently unused value for smRunIndex, which can be written into the smLaunchStart object associated with this row to launch a script. The value returned when reading this variable must be unique for the smLaunchOwner and smLauchName associated with this row. Subsequent attempts to read this variable must return different values. This variable will return the special value 0 if no new rows can be created." ::= { smLaunchEntry 14 } smLaunchStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines if this row is kept in volatile storage and lost upon reboot or if this row is backed up by stable storage. The value of smLaunchStorageType is only meaningful if the value of the corresponding RowStatus object is active. If smLaunchStorageType has the value permanent(4), then all objects whose MAX-ACCESS value is read-create must be writable, with the exception of the smLaunchStorageType and smLaunchRowStatus objects, which should be only be readable." DEFVAL { volatile } ::= { smLaunchEntry 15 } smLaunchRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "A control that allows entries to be added and removed from this table. Attempts to `destroy' a row or to set a row `notInService' while scripts started from this launch button are running will result in an inconsistentValue error. Expires December 1998 [Page 31] Internet-Draft Script MIB July 1998 Attempts to `destroy' a row or to set a row `notInService' where the value of the smLaunchStorageType object is `permanent' or `readOnly' will result in an inconsistentValue error." ::= { smLaunchEntry 16 } smRunTable OBJECT-TYPE SYNTAX SEQUENCE OF SmRunEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists and describes scripts that are currently running or have been running in the past." ::= { smRunObjects 2 } smRunEntry OBJECT-TYPE SYNTAX SmRunEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular running or finished script." INDEX { smLaunchOwner, smLaunchName, smRunIndex } ::= { smRunTable 1 } SmRunEntry ::= SEQUENCE { smRunIndex Unsigned32, smRunArgument OCTET STRING, smRunStartTime DateAndTime, smRunEndTime DateAndTime, smRunLifeTime TimeInterval, smRunExpireTime TimeInterval, smRunExitCode INTEGER, smRunResult OCTET STRING, smRunControl INTEGER, smRunState INTEGER } smRunIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The locally arbitrary, but unique identifier associated with this running or finished script. This value must be unique for all rows in the smRunTable." Expires December 1998 [Page 32] Internet-Draft Script MIB July 1998 ::= { smRunEntry 1 } smRunArgument OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The argument supplied to the script when it started." DEFVAL { ''H } ::= { smRunEntry 2 } smRunStartTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time when when the execution started. The value '0000000000000000'H is returned if the script has not started yet." DEFVAL { '0000000000000000'H } ::= { smRunEntry 3 } smRunEndTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time when when the execution terminated. The value '0000000000000000'H is returned if the script has not terminated yet." DEFVAL { '0000000000000000'H } ::= { smRunEntry 4 } smRunLifeTime OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies how long the script can execute. This object returns the remaining time that the script may run. The object is initialized with the value of the associated smLaunchLifeTime object and ticks backwards. The script is aborted immediately when the value reaches 0. The value of this object may be set in order to increase or reduce the remaining time that the script may run. Setting this value to 0 will abort script execution immediately, Expires December 1998 [Page 33] Internet-Draft Script MIB July 1998 and, if the value of smRunExpireTime is also 0, will remove this entry from the smRunTable once it has terminated. The value of smRunLifeTime reflects the real-time execution time as seen by the outside world. The value of this object will always be 0 for a script that finished execution, that is smRunState has the value `terminated'. The value of smRunLifeTime does not change while a script is suspended, that is smRunState has the value `suspended'." ::= { smRunEntry 5 } smRunExpireTime OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-write STATUS current DESCRIPTION "This value specifies how long this row can exist in the smRunTable after the script has terminated. This object returns the remaining time that the row may exist before it is aged out. The object is initialized with the value of the associated smLaunchExpireTime object and ticks backwards. The entry in the smRunTable is destroyed when the value reaches 0 and the smRunState has the value `terminated'. The value of this object may be set in order to increase or reduce the remaining time that the row may exist. Setting the value to 0 will destroy this entry as soon as the smRunState has the value `terminated'." ::= { smRunEntry 6 } smRunExitCode OBJECT-TYPE SYNTAX INTEGER { noError(1), halted(2), lifeTimeExceeded(3), noResourcesLeft(4), languageError(5), runtimeError(6), invalidArgument(7), securityViolation(8), genericError(9) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object indicates the reason why a Expires December 1998 [Page 34] Internet-Draft Script MIB July 1998 script finished execution. The smRunExitCode code may have one of the following values: - `noError', which indicates that the script completed successfully without errors; - `halted', which indicates that the script was halted by a request from an authorized manager; - `lifeTimeExceeded', which indicates that the script exited because a time limit was exceeded; - `noResourcesLeft', which indicates that the script exited because it ran out of resources (e.g. memory); - `languageError', which indicates that the script exited because of a language error (e.g. a syntax error in an interpreted language); - `runtimeError', which indicates that the script exited due to a runtime error (e.g. a division by zero); - `invalidArgument', which indicates that the script could not be run because of invalid script arguments; - `securityViolation', which indicates that the script exited due to a security violation; - `genericError', which indicates that the script exited for an unspecified reason. If the script has not yet begun running, or is currently running, the value will be `noError'." DEFVAL { noError } ::= { smRunEntry 7 } smRunResult OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The result value produced by the running script. This object should contain a descriptive error message if the script terminates in an abnormal way. In particular, an implementation should try to put a descriptive error message into this object if the script exits with the smRunExitCode `genericError'." Expires December 1998 [Page 35] Internet-Draft Script MIB July 1998 DEFVAL { ''H } ::= { smRunEntry 8 } smRunControl OBJECT-TYPE SYNTAX INTEGER { abort(1), suspend(2), resume(3), nop(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object indicates the desired status of the script execution defined by this row. Setting this object to `abort' will abort execution if the value of smRunState is `initializing', `executing', `suspending', `suspended' or `resuming'. Setting this object to `abort' when the value of smRunState is `aborting' or `terminated' will result in an inconsistentValue error. Setting this object to `suspend' will suspend execution if the value of smRunState is `executing'. Setting this object to `suspend' will cause an inconsistentValue error if the value of smRunState is not `executing'. Setting this object to `resume' will resume execution if the value of smRunState is `suspending' or `suspended'. Setting this object to `resume' will cause an inconsistentValue error if the value of smRunState is not `suspending' or `suspended'. Setting this object to nop(4) will always succeed and has no effect." DEFVAL { nop } ::= { smRunEntry 9 } smRunState OBJECT-TYPE SYNTAX INTEGER { initializing(1), executing(2), suspending(3), suspended(4), resuming(5), aborting(6), terminated(7) Expires December 1998 [Page 36] Internet-Draft Script MIB July 1998 } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object indicates the script's execution status. If the script has been invoked but has not yet begun execution, the value will be `initializing'. If the script is running, the value will be `executing'. A script which received a request to suspend execution but which did not actually suspend execution will be `suspending'. A script which has suspended execution will be `suspended'. A script which received a request to resume execution but which is not yet running is `resuming'. The resuming state will finally lead to the `executing' state. A script which received a request to abort execution but which is still running is `aborting'. A script which stopped execution is `terminated'." ::= { smRunEntry 10 } -- -- Notifications. The definition of smTraps makes notification -- registrations reversible. -- smTraps OBJECT IDENTIFIER ::= { smNotifications 0 } smScriptAbort NOTIFICATION-TYPE OBJECTS { smRunExitCode } STATUS current DESCRIPTION "This notification is generated whenever a running script terminates with an smRunExitCode unequal to `noError'." ::= { smTraps 1 } smScriptResult NOTIFICATION-TYPE OBJECTS { smRunResult } STATUS current DESCRIPTION "This notification can be used by scripts to notify other management applications about script results. It can be used to notify managers about a script result. This notification is not automatically generated by the script MIB implementation. It is the responsibility of the executing script to emit this notification where it is appropriate to do so." ::= { smTraps 2 } Expires December 1998 [Page 37] Internet-Draft Script MIB July 1998 -- conformance information smCompliances OBJECT IDENTIFIER ::= { smConformance 1 } smGroups OBJECT IDENTIFIER ::= { smConformance 2 } -- compliance statements smCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement the script MIB." MODULE -- this module MANDATORY-GROUPS { smLanguageGroup, smScriptGroup, smLaunchGroup, smRunGroup } GROUP smCodeGroup DESCRIPTION "The smCodeGroup is mandatory only for those implementations that support the downloading of scripts via SNMP." OBJECT smScriptSource MIN-ACCESS read-only DESCRIPTION "The smScriptSource object is read-only for implementations that are not able to download script code from a URL." OBJECT smRunState DESCRIPTION "A compliant implementation does not have to support script suspension and the smRunState `suspended'. Such an implementation will change into the `suspending' state when the smRunControl is set to `suspend' and remain in this state until smRunControl is set to `resume' or the script terminates." ::= { smCompliances 1 } smLanguageGroup OBJECT-GROUP OBJECTS { smLangLanguage, smLangVersion, smLangVendor, smLangRevision, smLangDescr, smExtsnExtension, smExtsnVersion, smExtsnVendor, smExtsnRevision, smExtsnDescr Expires December 1998 [Page 38] Internet-Draft Script MIB July 1998 } STATUS current DESCRIPTION "A collection of objects providing information about the capabilities of the scripting engine." ::= { smGroups 1 } smScriptGroup OBJECT-GROUP OBJECTS { smScriptDescr, smScriptLanguage, smScriptSource, smScriptAdminStatus, smScriptOperStatus, smScriptStorageType, smScriptRowStatus } STATUS current DESCRIPTION "A collection of objects providing information about installed scripts." ::= { smGroups 2 } smCodeGroup OBJECT-GROUP OBJECTS { smCodeText, smCodeRowStatus } STATUS current DESCRIPTION "A collection of objects used to download or modify scripts by using SNMP set requests." ::= { smGroups 3 } smLaunchGroup OBJECT-GROUP OBJECTS { smLaunchScriptOwner, smLaunchScriptName, smLaunchArgument, smLaunchMaxRunning, smLaunchMaxCompleted, smLaunchLifeTime, smLaunchExpireTime, smLaunchStart, smLaunchControl, smLaunchAdminStatus, smLaunchOperStatus, Expires December 1998 [Page 39] Internet-Draft Script MIB July 1998 smLaunchRunIndexNext, smLaunchStorageType, smLaunchRowStatus } STATUS current DESCRIPTION "A collection of objects providing information about scripts that can be launched." ::= { smGroups 4 } smRunGroup OBJECT-GROUP OBJECTS { smRunArgument, smRunStartTime, smRunEndTime, smRunLifeTime, smRunExpireTime, smRunExitCode, smRunResult, smRunState, smRunControl } STATUS current DESCRIPTION "A collection of objects providing information about running scripts." ::= { smGroups 5 } smNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { smScriptAbort, smScriptResult } STATUS current DESCRIPTION "The notifications emitted by the script MIB." ::= { smGroups 6 } END Expires December 1998 [Page 40] Internet-Draft Script MIB July 1998 7. Usage Examples This section presents some examples that explain how a manager can use the Script MIB defined in this memo. The purpose of these examples is to explain the steps that are normally used to delegate management scripts. 7.1. Pushing a script via SNMP This example explains the steps performed by a manager to push a script into a distributed manager. 1. The manager first checks the smLanguageTable and the smExtensionTable in order to select the appropriate script or language. 2. The manager creates a row in the smScriptTable by issuing an SNMP set-request. The smScriptRowStatus object is set to `createAndWait' and the smScriptSource object is set to an empty string. The smScriptLanguage object is set to the language that should be used to execute the scipt. The smScriptStorageType object is set to `volatile' to indicate that the script will be loaded via the smCodeTable. The smScriptOwner is set to a string which identifies the principal who owns the new row. The smScriptName defines the administratively assigned unique name for the script. 3. The manager sets the smScriptRowStatus object to `active' and the smScriptAdminStatus object to `editing'. 4. The manager pushes the script to the distributed manager by issuing a couple of SNMP set-requests to fill the smCodeTable. 5. Once the whole script has been transferred, the manager sends a set-request to set the smScriptAdminStatus object to `enabled'. The Script MIB implementation now makes the script accessible to the runtime system. This might include the compilation of the script if the language requires a compilation step. 6. The manager polls the smScriptOperStatus object until the value is either `enabled' or one of the error status codes. The script can only be used if the value of smScriptOperStatus is `enabled'. 7. If the manager wants to store the script in local non-volatile storage, it should send a set-request which changes the Expires December 1998 [Page 41] Internet-Draft Script MIB July 1998 smScriptStorageType object to `nonVolatile'. 7.2. Pulling a script from a URL This example explains the steps performed by a manager to pull a script from a URL. 1. The manager first checks the smLanguageTable and the smExtensionTable in order to select the appropriate script or language. 2. The manager creates a row in the smScriptTable by issuing an SNMP set-request. The smScriptRowStatus object is set to `createAndWait' and the smScriptSource object is set to the URL which points to the script source. The smScriptLanguage object is set to the language that should be used to execute the scipt. The smScriptOwner is set to a string which identifies the principal who owns the new row. The smScriptName defines the administratively assigned unique name for the script. 3. The manager sets the smScriptRowStatus object to `active'. 4. The manager sends a set-request to set the smScriptAdminStatus object to `enabled'. The Script MIB implementation now makes the script accessible to the runtime system. This causes a retrieval operation to pull the script from the URL stored in smScriptSource. This retrieval operation might be followed by a compile operation if the language requires a compilation step. 5. The manager polls the smScriptOperStatus object until the value is either `enabled' or one of the error status codes. The script can only be used if the value of smScriptOperStatus is `enabled'. 6. If the manager wants to store the script in local non-volatile storage, it should send a set-request which changes the smScriptStorageType object to `nonVolatile'. 7.3. Modifying an existing script This section explains how a manager can modify a script by send SNMP set-requests. 1. First, the script is de-activated by setting the smScriptAdminStatus to `disabled'. Expires December 1998 [Page 42] Internet-Draft Script MIB July 1998 2. The manager polls the smScriptOperStatus object until the value is `disabled'. 3. The manager sets smScriptSource to an empty string and smScriptAdminStatus to `editing'. This makes the script source available in the smCodeTable. 4. The manager polls the smScriptOperStatus object until the value is `editing'. 5. The manager sends SNMP set-requests to modify the script in the smCodeTable. 6. The manager sends a set-request to set the smScriptAdminStatus object to `enabled'. The Script MIB implementation now makes the script accessible to the runtime system. This might include the compilation of the script if the language requires a compilation step. 7. The manager polls the smScriptOperStatus object until the value is either `enabled' or one of the error status codes. The script can only be used if the value of smScriptOperStatus is `enabled'. 7.4. Removing an existing script This section explains how a manager can remove a script from a distributed manager. 1. First, the manager sets the smScriptAdminStatus to `disabled'. This will ensure that no new scripts can be started while running scripts finish their execution. 2. The manager polls the smScriptOperStatus object until the value is `disabled'. 3. The manager sends an SNMP set-request to change the smScriptRowStatus object to `destroy'. This will remove the row and all associated resources from the Script MIB implementation. 7.5. Creating a launch button This section explains how a manager can create a launch button for starting a script. Expires December 1998 [Page 43] Internet-Draft Script MIB July 1998 1. The manager, who is identified by an smLaunchOwner value, first chooses a name for the new row in the smLaunchTable. The manager sends an SNMP set-request to set the smLaunchRowStatus object for this smLaunchOwner and smLaunchName to `createAndWait'. 2. The manager fills the new smLaunchTable row with all required parameters. The smLaunchScriptOwner and smLaunchScriptName values point to the script that should be started from this launch button. 3. The manager sends a set-request to change smLaunchAdminStatus to `enabled' once the new smLaunchTable row is complete. 4. The manager polls the smLaunchOperStatus object until the value is `enabled'. 7.6. Launching a script This section explains the suggested way to launch a script from a given launch button. 1. The manager first retrieves the value of smLaunchRunIndexNext from the launch button selected to start the script. 2. The manager sends an SNMP set-request to set the smLaunchStart object to the value obtained in step 1. This will launch the script if all necessary pre-conditions are satisfied (see the definition of smLaunchStart for more details). The manager can also provide the smLaunchArgument in the same set-request that is used to start the script. Upon successful start, a new row will be created in the smRunTable indexed by smLaunchOwner, smLaunchName and the value written to smLaunchStart. Note, the first step is not required. A manager can also try to guess an unused value for smRunIndex if he wants to start script in a single transaction. A manager can also use the special value 0 if he does not care about the results produced by the script. 7.7. Terminating a script This section explains two ways to terminate a running script. The first approach is as follows: 1. The manager sets the smRunControl object of the running script or the smLaunchControl object of the launch button used to start Expires December 1998 [Page 44] Internet-Draft Script MIB July 1998 the running script to `abort'. Setting smLaunchControl will abort all running scripts started from the launch button while smRunControl will only abort the running script associated with the smRunControl instance. The second way to terminate a script is to set the smRunLifeTime to zero which causes the runtime system to terminate the script with a `lifeTimeExceeded' exit code: 1. The manager changes the value of smRunLifeTime to 0. This causes the Script MIB implementation to abort the script because the remaining life time has expired. Note, changing the smRunLifeTime value can also be used to increase the permitted lifetime of a running script. For example, a manager can choose to set smRunLifeTime to a small fixed time interval and increase the value periodically. This strategie has the nice effect that scripts terminate automatically if the manager looses contact with the Script MIB engine. 7.8. Removing a launch button This section explains how a manager can remove a launch button from a distributed manager. 1. First, the manager sets the smLaunchAdminStatus to `disabled'. This will ensure that no new scripts can be started from this launch button while running script will finish their execution. 2. The manager polls the smLaunchOperStatus object until the value is `disabled'. 3. The manager sends an SNMP set-request to change the smLaunchRowStatus object to `destroy'. This will remove the row and all associated resources from the Script MIB implementation. Expires December 1998 [Page 45] Internet-Draft Script MIB July 1998 8. VACM Configuration Examples This section shows how the view-based access control model defined in RFC 2275 [15] can be configured to control access to the script MIB. 8.1. Sandbox for guests The first example demonstrates how to configure VACM to give the members of the VACM group "guest" limited access to the script MIB. The MIB views defined below give the members of the "guest" group a sandbox where they can install and start their own scripts, but not access any other scripts maintained by the Script MIB implementation. vacmAccessReadView."guest"."".usm.authNoPriv = "guestReadView" vacmAccessWriteView."guest"."".usm.authNoPriv = "guestWriteView" The guestReadView grants read access to the smLangTable, the smExtsnTable and to all the table entries owned by "guest": guestReadView: smLangTable (included) smExtsnTable (included) smScriptObjects.*.*.*."guest" (included) smRunObjects.*.*.*."guest" (included) The guestWriteView grants write access to all the table entries owned by "guest": guestWriteView: smScriptObjects.*.*.*."guest" (included) smRunObjects.*.*.*."guest" (included) 8.2. Sharing scripts This example demonstrates how VACM can be used to share a repository of scripts between the members of the "senior" and the members of the "junior" VACM group: vacmAccessReadView."junior"."".usm.authNoPriv = "juniorReadView" vacmAccessWriteView."junior"."".usm.authNoPriv = "juniorWriteView" juniorReadView: Expires December 1998 [Page 46] Internet-Draft Script MIB July 1998 smLangTable (included) smExtsnTable (included) smScriptObjects.*.*.*."junior" (included) smRunObjects.*.*.*."junior" (included) smScriptObjects.*.*.*."utils" (included) juniorWriteView: smScriptObjects.*.*.*."junior" (included) smRunObjects.*.*.*."junior" (included) The definitions above allow the members of the "junior" VACM group to start the scripts owned by "utils" in addition to the script the members of the "junior" VACM group installed themself. This is accomplished by giving the members of "junior" read access to scripts in "utils". This allows members of "junior" to create entries in the smLauchTable which refer to scripts in "utils", and to launch those scripts using these entries in the smLaunchTable. vacmAccessReadView."senior"."".usm.authNoPriv = "seniorReadView" vacmAccessWriteView."senior"."".usm.authNoPriv = "seniorWriteView" seniorReadView: smLangTable (included) smExtsnTable (included) smScriptObjects.*.*.*."senior" (included) smRunObjects.*.*.*."senior" (included) smScriptObjects.*.*.*."utils" (included) seniorWriteView: smScriptObjects.*.*.*."senior" (included) smRunObjects.*.*.*."senior" (included) smScriptObjects.*.*.*."utils" (included) The definitions for the members of the "senior" VACM group allow to start the scripts owned by "utils" in addition to the script the members of the "senior" VACM group installed themself. The third write access rule in the seniorWriteView also grants the permission to install scripts owned by "utils". The members of the "senior" VACM group therefore have the permissions to install and modify scripts that can be called by the members of the "junior" VACM group. 8.3. Emergency scripts This example demonstrates how VACM can be used to allow the members Expires December 1998 [Page 47] Internet-Draft Script MIB July 1998 of the "junior" VACM group to launch scripts that are executed with the permissions associated with the "emergency" owner. This works by adding the following rules to the juniorReadView and the juniorWriteView: juniorReadView: smScriptObjects.*.*.*."emergency" (included) smRunObjects.*.*.*."emergency" (included) juniorWriteView smLaunchStart."emergency" (included) smLaunchArgument."emergency" (included) The rules added to the juniorReadView grant read access to the scripts, the launch buttons and the results owned by "emergency". The rules added to the juniorWriteView grant write permissions to the smLaunchStart and smLaunchArgument variables ownded by "emergency". Members of the "junior" VACM group can therefore start scripts that will execute under the owner "emergency". seniorReadView: smScriptObjects.*.*.*."emergency" (included) smRunObjects.*.*.*."emergency" (included) seniorWriteView: smScriptObjects.*.*.*."emergency" (included) smRunObjects.*.*.*."emergency" (included) The rules added to the seniorReadView and the seniorWriteView will give the members of the "senior" VACM group the rights to install emergency scripts and to configure appropriate launch buttons. 9. IANA Considerations The Internet Assigned Numbers Authority (IANA) is responsible to maintain a MIB module which provides OID registrations for well-known languages. The IANA language registry is intented to reduce interoperability problems by providing a single list of well-known languages. However, it is of course still possible to register languages in private OID spaces. Registering languages in private spaces is especially attractive if a language is used for experimentation or if a language is only used in environments where the distribution MIB modules with the language registration does not cause any maintenance problems. Any additions or changes to the list of languages registered via IANA Expires December 1998 [Page 48] Internet-Draft Script MIB July 1998 require Designated Expert Review as defined in the IANA guidelines [20]. The Designated Expert will be selected by the IESG Area Director for the IETF Operations and Management Area. 10. Security Considerations This MIB provides the ability to distribute applications written in an arbitrary language to remote systems in a network. The security features of the languages available in a particular implementation should be taken into consideration when deploying an implementation of this MIB. To facilitate the provisioning of access control by a security administrator using the View-Based Access Control Model (VACM) defined in RFC 2275 [15] for tables in which multiple users may need to independently create or modify entries, the initial index is used as an "owner index". Such an initial index has a syntax of SnmpAdminString, and can thus be trivially mapped to a securityName or groupName as defined in VACM, in accordance with a security policy. All entries in related tables belonging to a particular user will have the same value for this initial index. For a given user's entries in a particular table, the object identifiers for the information in these entries will have the same subidentifiers (except for the "column" subidentifier) up to the end of the encoded owner index. To configure VACM to permit access to this portion of the table, one would create vacmViewTreeFamilyTable entries with the value of vacmViewTreeFamilySubtree including the owner index portion, and vacmViewTreeFamilyMask "wildcarding" the column subidentifier. More elaborate configurations are possible. The VACM access control mechanism described above provides control over SNMP access to Script MIB objects. There are a number of other access control issues that are outside of the scope of this MIB. For example, access control on URLs, especially those that use the file scheme, must be realized by the underlying operating system. A mapping of the owner index value to a local operating system security user identity should be used by an implementation of this MIB to control access to operating system resources when resolving URLs or executing scripts. Expires December 1998 [Page 49] Internet-Draft Script MIB July 1998 11. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 12. Acknowledgments This document was produced by the IETF Distributed Management (DISMAN) working group. Expires December 1998 [Page 50] Internet-Draft Script MIB July 1998 13. References [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998 [2] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990 [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991 [4] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, Performance Systems International, March 1991 [5] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [6] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [7] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [8] 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. [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol Expires December 1998 [Page 51] Internet-Draft Script MIB July 1998 (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, SNMP Research, Inc., Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998. [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, IBM T. J. Watson Research, January 1998. [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2273, SNMP Research, Inc., Secure Computing Corporation, Cisco Systems, January 1998 [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, Inc., Cisco Systems, Inc., January 1998 [16] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [17] Berners-Lee, T., Masinter, L., and M. McCahill, Editors, "Uniform Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of Minnesota, December 1994. [18] Postel, J., and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, ISI, October 1985. [19] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners- Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, UC Irvine, DEC, MIT/LCS, January 1997. [20] Narten, T., and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", Internet Draft , IBM, UNINETT, May 1998. Expires December 1998 [Page 52] Internet-Draft Script MIB July 1998 14. Editors' Addresses David B. Levi Email: levi@snmp.com SNMP Research, Inc. Tel: +1 423 573 1434 3001 Kimberlin Heights Road Knoxville, TN 37920-9716 U.S.A. Juergen Schoenwaelder Email: schoenw@ibr.cs.tu-bs.de TU Braunschweig Tel: +49 531 391-3683 Bueltenweg 74/75 38106 Braunschweig Germany 15. Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires December 1998 [Page 53] Internet-Draft Script MIB July 1998 16. IANA Language Registration MIB This appendix defines the initial content of the IANA-LANGUAGE-MIB. This section should be removed from this document prior to its approval, at which time this MIB will be administered by IANA. IANA-LANGUAGE-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-IDENTITY, experimental FROM SNMPv2-SMI; ianaLanguages MODULE-IDENTITY LAST-UPDATED "9807170000Z" ORGANIZATION "IANA" CONTACT-INFO "Internet Assigned Numbers Authority (IANA) Postal: USC/Information Sciences Institute 4676 Admiralty Way, Marina del Rey, CA 90292 Tel: +1 310 822 1511 E-Mail: iana@isi.edu" DESCRIPTION "The MIB module registers object identifier values for well-known programming and scripting languages. Any additions or changes to the contents of this MIB module require Designated Expert Review as defined in the Guidelines for Writing IANA Considerations Section document. The Designated Expert will be selected by the IESG Area Director of the OPS Area. Note that this module does not have to register all possible languages since languages are identified by object identifier values. It is therefore possible to registered language in private OID trees. The references given below are not normative with regard to the language version. Other references might be better suited to describe some newer versions of this language. The references are only provided as `a pointer into the right direction'." -- XXX Replace with real registration number from IANA. Note, the -- XXX IMPORTS must be updated when the real number is assigned. ::= { experimental 9876 } Expires December 1998 [Page 54] Internet-Draft Script MIB July 1998 ianaLangJavaVM OBJECT-IDENTITY STATUS current DESCRIPTION "The Java virtual machine." REFERENCE "The Java Virtual Machine Specification. ISBN 0-201-63452-X" ::= { ianaLanguages 1 } ianaLangTcl OBJECT-IDENTITY STATUS current DESCRIPTION "The Tool Command Language (Tcl)." REFERENCE "Tcl and the Tk Toolkit. ISBN 0-201-63337-X" ::= { ianaLanguages 2 } ianaLangPerl OBJECT-IDENTITY STATUS current DESCRIPTION "The Perl Language." REFERENCE "Programming Perl. ISBN 1-56592-149-6" ::= { ianaLanguages 3 } ianaLangScheme OBJECT-IDENTITY STATUS current DESCRIPTION "The Scheme Language." REFERENCE "The Revised^4 Report on the Algorithmic Language Scheme. MIT Press" ::= { ianaLanguages 4 } ianaLangSSL OBJECT-IDENTITY STATUS current DESCRIPTION "The SNMP Script Language defined by SNMP Research." ::= { ianaLanguages 5 } ianaLangPSL OBJECT-IDENTITY STATUS current DESCRIPTION "The Patrol Script Language defined by BMC Software." REFERENCE Expires December 1998 [Page 55] Internet-Draft Script MIB July 1998 "PATROL Script Language Reference Manual, Version 3.0, November 30, 1995. BMC Software, Inc. 2101 City West Blvd., Houston, Texas 77042." ::= { ianaLanguages 6 } ianaLangSMSL OBJECT-IDENTITY STATUS current DESCRIPTION "The Systems Management Scripting Language." REFERENCE "ISO/ITU Command Sequencer. ISO 10164-21 or ITU X.753" ::= { ianaLanguages 7 } END Expires December 1998 [Page 56] Internet-Draft Script MIB July 1998 17. Revision History This section should be removed once this document gets published as an RFC. 17.1. Changes from o Removed smLanguageVersion from the INDEX clause of smLanguageEntry. o Changed the order of smLanguageVersion and smLanguageID to make it consistent with the smExtensionTable. o Changed the definition of OwnerString so that it is compatible with the RMON definition. (The OwnerString definition should be defined in the DISMAN MIB.) o Clarified the definition of UniformResourceLocator to use the character set and encodings as defined by RFC 1738. o Changed the definition of VersionString to use a DisplayString as a base type. Changes the maximum length to 31 octets so that it easily fits into a 32 byte null-terminated string. o Restricted the values of smLanguageIndex to positive numbers. o Changed to allow modification of smScriptSource if smRowStatus is notReady. o Changed the type of smExecInterval to Unsigned32. o Changed the order of the first two operations in example 11.3. o Added a default value to smExecLastError, smExecInterval and smExecLastFinished. o Changed the wording of requirement 1 to avoid the term "concrete language". o Clarified the requirement to handle multiple version of the same script as well as scripts with the same administrative name owned by different managers in section 4.2. o Added text to the smScriptRowStatus description which requires to reset the smScriptOperStatus to unknown if the Expires December 1998 [Page 57] Internet-Draft Script MIB July 1998 smScriptRowStatus is set to notInService. Also clarified that the value of smScriptAccess must be notAccessible or readOnly when setting smScriptRowStatus to active. o Added some more DEFVALs for RowStorage and some other objects. o Changes the range of smScriptNext and smExecNext to more reasonable values. Allow the value 0 so that the agent can give a hint if we have reached a resource limit (Perkins). o Moved the smCodeTable into the smScript group and removed the smCode group. o Changed the maximum size of smExecArgument and smExecLastResult to 2048. o Minor modifications to the MIB so that it passes the smicng compiler contained in Dave Perkins and Evan McGinnis book. o Rewrote the smExec group. The scheduling mechanism has been removed and the smExecTable has been split into the smExecTable and the smRunTable. o Changed the smScriptOperStatus state `loading' into `retrieving' to avoid confusion with runtime systems that have a loading phase. o Rewrote some paragraphs in the text to document the smExecTable and the smRunTable. o More changes in the smExecTable and the smRunTable. o Replaced the RowStorage TC with RFC 1903 StorageType since there are code bases that already support this TC. 17.2. Changes from o Split the OBJECT-GROUP definition into smaller pieces. Changed the the compliance definition to full compliance. This permits the creation of additional compliance statements for agents with different capabilities (for example, agents which do not permit downloading or modifying scripts). o Changed the name of the smExecTable to smLaunchTable to avoid confusing. Expires December 1998 [Page 58] Internet-Draft Script MIB July 1998 o Changed the names of the following objects as follows: smRunLifeTime -> smRunLifeTime smRunCompletedLifeTime -> smRunExpireTime smLaunchRunningLifeTime -> smLaunchLifeTime smLaunchCompletedLifeTime -> smLaunchExpireTime o Fixed the registration of smLanguageID, smLanguageVersion, smRunNext and smRunTable to close some gaps. o Clarified that smRunLifeTime is always 0 when a script has finished execution. o Removed the smScriptAccess. The SNMP access control model should be used to control whether script source is readable/writable or invisible. o Changed smScriptRowStorage and smLaunchRowStorage to smScriptStorageType and smLaunchStorageType which is more consistent with other MIBs. o Changed smScriptRowOwner and smLaunchRowOwner to smScriptOwner and smLaunchOwner. o Split the section about open and closed issues into two separate sections. 17.3. Changes from o Added PSL and SMSL to the language directory. o Added the IPR section required by RFC 2026. o Clearified that languages may be registered in other branches of the OID registration tree. o Replaced "continue" with "resume". o Removed the consecutive value constaint for smCodeIndex. o Relaxed the index ranges from 1..65535 to 1..2147483647. o Turned the script exit codes into a textual convention. o The compliance macro allows implementations that do not support the push nor the pull model to download script code. Expires December 1998 [Page 59] Internet-Draft Script MIB July 1998 o Changed the definition of smRunOperStatus to a) allow transient states between reception of a `signal' and the actual state change b) to use only one state to represent a terminated script. The smRunExitCode object contains the information necessary to distinguish between an aborted script and a script which terminates normally. o Added a smScriptAbort notification as discussed in San Jose. o Removed the index component smLanguageIndex from the smScriptTable, the smCodeTable, the smLaunchTable and the smRunTable. Added a new smScriptLanguage column which identifies the language. o Replaced DisplayStrings with SnmpAdminStrings to facilitate internationalization. o Removed the sections on open and closed issues. o Added smLauchAdminStatus and smLauchOperStatus. Added a note that writing smLauchStart will result in an inconsistentValue error if the value of smLauchOperStatus is disabled. o Updated the section about the SNMP management framework and added references to SNMPv3. o Added the smScriptAdminStatus object and renamed the smScriptStatus object to smScriptOperStatus. Renamed some of the states of the smScriptOperStatus object and added a short explanation for each possible state. o Changed the indexing scheme to use owner string as the first component. o Clarified the value of smRunStartTime and smRunEndTime after discontinuities. o Updated the usage examples to reflect the recent changes. 17.4. Changes from o Fixed a few typos. o Removed the text from the description of smScriptRowStatus which explained when a script is known by the runtime system. Expires December 1998 [Page 60] Internet-Draft Script MIB July 1998 o Removed the size constraints from and smLaunchArgument, smRunArgument and smRunResult. Added text that script designers might want to return pointers to results instead of the result itself if it can get very large. o Added reference to BCP-11. o Added the new boilerplate and the references that go along with it. o Renamed smRunOperStatus to smRunState and smRunAdminStatus to smRunControl. smRunControl is now identical to smLaunchControl with the exeception that smLaunchControl "loops" over all smRunControl objects that belong to a particular launch button. This change also allows to define a semantically sound default value for smLaunchControl (previously smRunAdminStatus). o RowStatus clarifications when you are allowed to destroy a row or take a row out of service. o Clarified that smRunLifeTime is frozen while the running script is suspended. o Added a new notification smScriptResult which can be used by scripts to send results via traps and informs. Changed the description of smRunResult so that it can contain results while the script is still executing. o The smCodeText size restriction now starts at 1 instead of 0. o Changed the data type of smRunStartTime and smRunEndTime from TimeStamp to DateAndTime. Added text to the description how these objects are initialized. o Changed smLaunchMaxRunning and smLaunchMaxCompleted from Integer32 (1..1024) to Unsigned32 (1..4294967295). o Added the IANA-LANGUAGE-MIB and added an "IANA Considerations" section with appropriate references. Clarified the meaning of the REFERENCE clauses in the IANA-LANGUAGE-MIB. o Added text to section 4.2 that neither the push nor the pull model are required and that the MIB can also be used with hard- wired scripts. o Restructured section 5 along the object groups. For each group, list the operations provided by this group. Expires December 1998 [Page 61] Internet-Draft Script MIB July 1998 o Removed the intermediate smLanguage, smScript and smExec nodes. Renamed the smLanguage and the smExtension table and added attributes for the language vendor and the implementation version number. o Changed smLangIndex, smExtsnIndex, smCodeIndex, smRunNext, smRunIndex from Integer32 to Unsigned32 for `architectural purity'. o Changed the indexing structure to use (smScriptOwner, smScriptName) instead of (smScriptOwner, smScriptIndex) and (smLaunchOwner, smLaunchName) instead of (smLaunchOwner, smLaunchIndex). Removed the smScriptNext, the smLaunchNext and the smScriptVersion objects. o Moved the smRunNext object into the smLaunchTable (smLaunchRunIndexNext) so that we generate unique smRunIndex values for a given (smLaunchOwner, smLaunchName). o The tuple (smLaunchScriptOwner, smLaunchScriptName) now refers to the script in the smScriptTable. These objects can not be modified as long as the smLaunchTable entry is enabled. o Changed the MIB module name to DISMAN-SCRIPT-MIB. o Changed smScriptSource data type to DisplayString and added text to explain the difference between a "file:/..." URL and an empty value. o Added text to the security considerations section. (Needs probably more work.) o Added a more detailed description how write attempts to smLaunchStart are handled. o Merged the ExitCode TC into the smRunExitCode object as it is only used once. o Merged the VersionString TC into the objects that used this TC. This avoids any problems with regard to TC subtyping at a reasonable cost. o Added a clause to the compliance statement that script suspension is not required in order to be compliant. o Added two intermediate MIB nodes (smScriptObjects and smRunObjects) in order to group tables with similar indexing Expires December 1998 [Page 62] Internet-Draft Script MIB July 1998 structures together. This allows to make use of the VACM wildcarding mechanism to reduce the total number of VACM entries. 17.5. Changes from o Some clarifications for smRunLifeTime and smRunExpireTime. o Added VACM configuration examples. o Moved the change logs to the end of the document. Expires December 1998 [Page 63] Internet-Draft Script MIB July 1998 Table of Contents 1 Abstract ..................................................... 2 2 The SNMP Management Framework ................................ 2 3 Overview ..................................................... 3 3.1 Terms ...................................................... 3 4 Requirements and Design Issues ............................... 4 4.1 Script Languages ........................................... 5 4.2 Script Transfer ............................................ 6 4.3 Script Execution ........................................... 7 5 The Structure of the MIB ..................................... 8 5.1 The smLanguageGroup ........................................ 8 5.2 The smScriptGroup .......................................... 8 5.3 The smCodeGroup ............................................ 9 5.4 The smLaunchGroup .......................................... 10 5.5 The smRunGroup ............................................. 10 6 Definitions .................................................. 12 7 Usage Examples ............................................... 41 7.1 Pushing a script via SNMP .................................. 41 7.2 Pulling a script from a URL ................................ 42 7.3 Modifying an existing script ............................... 42 7.4 Removing an existing script ................................ 43 7.5 Creating a launch button ................................... 43 7.6 Launching a script ......................................... 44 7.7 Terminating a script ....................................... 44 7.8 Removing a launch button ................................... 45 8 VACM Configuration Examples .................................. 46 8.1 Sandbox for guests ......................................... 46 8.2 Sharing scripts ............................................ 46 8.3 Emergency scripts .......................................... 47 9 IANA Considerations .......................................... 48 10 Security Considerations ..................................... 49 11 Intellectual Property ....................................... 50 12 Acknowledgments ............................................. 50 13 References .................................................. 51 14 Editors' Addresses .......................................... 53 15 Full Copyright Statement .................................... 53 16 IANA Language Registration MIB .............................. 54 17 Revision History ............................................ 57 17.1 Changes from ........ 57 17.2 Changes from ........ 58 17.3 Changes from ........ 59 17.4 Changes from ........ 60 17.5 Changes from ........ 63 Expires December 1998 [Page 64] From maria@xedia.com Mon Jul 20 20:27:22 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 UAA21587 for ; Mon, 20 Jul 1998 20:27:21 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id UAA07517 for ; Mon, 20 Jul 1998 20:26:33 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma007502; Mon, 20 Jul 98 20:26:11 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id UAA06194 for ; Mon, 20 Jul 1998 20:25:37 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma006170; Mon, 20 Jul 98 20:25:32 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id UAA17667; Mon, 20 Jul 1998 20:26:06 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id SAA07263 for ; Mon, 20 Jul 1998 18:26:04 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id UAA23538 for ; Mon, 20 Jul 1998 20:26:02 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma023521; Mon, 20 Jul 98 20:25:31 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id SAA01384 for ; Mon, 20 Jul 1998 18:21:38 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id VAA23183 for ; Mon, 20 Jul 1998 21:00:23 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id UAA06685 for ; Mon, 20 Jul 1998 20:00:22 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma006672; Mon, 20 Jul 98 20:00:07 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id TAA27700 for ; Mon, 20 Jul 1998 19:59:32 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma027589; Mon, 20 Jul 98 19:59:21 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id TAA13448 for ; Mon, 20 Jul 1998 19:59:54 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA06992 for disman@nexen.com; Mon, 20 Jul 1998 17:59:54 -0700 (PDT) Date: Mon, 20 Jul 1998 17:59:54 -0700 (PDT) From: Randy Presuhn Message-Id: <199807210059.RAA06992@dorothy.bmc.com> To: disman@nexen.com Subject: WG Last Call: schedule MIB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - Juergen and David have posted to this mailing list, and it should soon appear in the usual FTP repositories. As disman chair, I am issuing a Working Group Last Call on this document, with a deadline for comments of July 31, 1998. At that time, if nothing terrible is discovered, we'll forward it to the IESG for publication as a Proposed Standard. If significant issues surface or there is other good reason for an extension of the deadline, it will be adjusted appropriately and we'll cycle until we get it right. :-) ----------------------------------------------------------------------- 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 maria@xedia.com Mon Jul 20 20:27:22 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 UAA21588 for ; Mon, 20 Jul 1998 20:27:21 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id UAA07519 for ; Mon, 20 Jul 1998 20:26:33 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma007503; Mon, 20 Jul 98 20:26:11 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id UAA06193 for ; Mon, 20 Jul 1998 20:25:37 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma006083; Mon, 20 Jul 98 20:25:14 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id UAA17617; Mon, 20 Jul 1998 20:25:47 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id SAA07251 for ; Mon, 20 Jul 1998 18:25:34 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id UAA07479 for ; Mon, 20 Jul 1998 20:25:33 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma007459; Mon, 20 Jul 98 20:25:04 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id SAA01444 for ; Mon, 20 Jul 1998 18:27:12 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id VAA23191 for ; Mon, 20 Jul 1998 21:05:53 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id UAA06838 for ; Mon, 20 Jul 1998 20:05:52 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma006832; Mon, 20 Jul 98 20:05:37 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id UAA29434 for ; Mon, 20 Jul 1998 20:05:02 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma029402; Mon, 20 Jul 98 20:04:57 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id UAA14373 for ; Mon, 20 Jul 1998 20:05:30 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id SAA07029 for disman@nexen.com; Mon, 20 Jul 1998 18:05:30 -0700 (PDT) Date: Mon, 20 Jul 1998 18:05:30 -0700 (PDT) From: Randy Presuhn Message-Id: <199807210105.SAA07029@dorothy.bmc.com> To: disman@nexen.com Subject: WG Last Call: Script MIB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - Juergen and David have posted to this mailing list, and it should soon appear in the usual FTP repositories. As disman chair, I am issuing a Working Group Last Call on this document, with a deadline for comments of July 31, 1998. As this is a fairly lengthy document, if you are COMMITTED to making comments and need an extended deadline in order to do so, please request the extension NOW. At the close of WG last call, if nothing terrible has been discovered, we'll forward it to the IESG for publication as a Proposed Standard. If significant issues surface or there is other good reason for an extension of the deadline, it will be adjusted appropriately and we'll cycle until we get it right. :-) ----------------------------------------------------------------------- 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 maria@xedia.com Mon Jul 20 21:52:50 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 VAA22262 for ; Mon, 20 Jul 1998 21:52:50 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id VAA10261 for ; Mon, 20 Jul 1998 21:52:02 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma010258; Mon, 20 Jul 98 21:51:55 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id VAA28248 for ; Mon, 20 Jul 1998 21:51:20 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma028225; Mon, 20 Jul 98 21:51:14 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id VAA00980; Mon, 20 Jul 1998 21:51:37 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id TAA07600 for ; Mon, 20 Jul 1998 19:51:31 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id VAA10233 for ; Mon, 20 Jul 1998 21:51:29 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma010187; Mon, 20 Jul 98 21:50:57 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id TAA02320 for ; Mon, 20 Jul 1998 19:46:05 -0400 (EDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id WAA23342 for ; Mon, 20 Jul 1998 22:24:59 -0400 (EDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id WAA11068; Mon, 20 Jul 1998 22:24:45 -0400 Received: from watpub1.watson.ibm.com (watpub1.watson.ibm.com [9.2.101.12]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id WAA09962; Mon, 20 Jul 1998 22:24:44 -0400 Received: by watpub1.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA45646; Mon, 20 Jul 1998 22:24:43 -0400 From: Uri Blumenthal Message-Id: <9807210224.AA45646@watpub1.watson.ibm.com> Subject: Re: VACM and DISMAN To: rpresuhn@dorothy.bmc.com (Randy Presuhn) Date: Mon, 20 Jul 1998 22:24:43 -0400 (EDT) Cc: disman@nexen.com, snmpv3@tis.com In-Reply-To: <199807070015.RAA17489@dorothy.bmc.com> from "Randy Presuhn" at Jul 6, 98 05:15:20 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Randy Presuhn says: > It seems like the other appropach you outlined makes more > sense, where the administrator defines for each user a set of > _in_ securityNames with the supporting USM entries and > vacmSecurityToGroupEntries. In this case, one would only need > groups and avoid excessive duplication of subtree information. The > downside is that the command generator would have to be explicit about > the role in which the user is acting, and the security administrator > would need to be aware of those roles. This is probably not a bad thing. 1. "Role-based" authorization models usually have separate [independent] policies for roles known AND for users known. Each decision is made based on what the CONJUNCTION of the User and Role permissions are. For example: A role "operator" has access rights X. A role "netadmin" has access rights Y. A user "randy" has general access rights Z. So when a request comes from "randy-in_role-operator", the access rights to check it against will be what is included in the set "X AND Z". Whatever is not included in BOTH will automatically be forbidden. The main reason for role-based models is to be able to modify roles independently from principals and vs. versa. It is NOT easy to design and administer a good role-based access control model. 2. It usually is a very bad idea to allow the receiving entity to guess what role to apply, especially so if the guessing algorithm is "go for the mightiest access". Those who know me, have already figured out that I'm tempted to use a much stronger word than just "bad". 3. Sometimes when people say "role-based", what they really mean is: We want to have just a few access control policies, like "any operator can do X, any netadmin can do Y and any superuser can do Z", but we want to maintain a detailed log of who-did-what, including name-and-serial-number. So the "principal" ID goes into the log, but the access control is decided using the "role" rather than the "principal". In any case, the request MUST carry the "role" or the "group" tag in it, for anything role-based to make any sense at all. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From maria@xedia.com Mon Jul 20 21:52:50 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 VAA22263 for ; Mon, 20 Jul 1998 21:52:50 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id VAA10263 for ; Mon, 20 Jul 1998 21:52:02 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma010259; Mon, 20 Jul 98 21:51:55 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id VAA28246 for ; Mon, 20 Jul 1998 21:51:20 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma028222; Mon, 20 Jul 98 21:51:13 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id VAA00944; Mon, 20 Jul 1998 21:51:30 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id TAA07597 for ; Mon, 20 Jul 1998 19:51:28 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id VAA26699 for ; Mon, 20 Jul 1998 21:51:27 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma026671; Mon, 20 Jul 98 21:50:58 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id TAA02352 for ; Mon, 20 Jul 1998 19:52:50 -0400 (EDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id WAA16067 for ; Mon, 20 Jul 1998 22:31:45 -0400 (EDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id WAA16616; Mon, 20 Jul 1998 22:31:41 -0400 Received: from watpub1.watson.ibm.com (watpub1.watson.ibm.com [9.2.101.12]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id WAA12212; Mon, 20 Jul 1998 22:31:40 -0400 Received: by watpub1.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA30262; Mon, 20 Jul 1998 22:31:40 -0400 From: Uri Blumenthal Message-Id: <9807210231.AA30262@watpub1.watson.ibm.com> Subject: Re: VACM and DISMAN To: schoenw@ibr.cs.tu-bs.de (Juergen Schoenwaelder) Date: Mon, 20 Jul 1998 22:31:39 -0400 (EDT) Cc: rpresuhn@dorothy.bmc.com, disman@nexen.com, snmpv3@tis.com In-Reply-To: <199807070904.LAA01088@henkell.ibr.cs.tu-bs.de> from "Juergen Schoenwaelder" at Jul 7, 98 11:04:37 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Juergen Schoenwaelder says: > .......I also have concerns that management applications will provide > the support necessary to make this work in practice (that is providing > the intelligence to automatically select the "right" identities). It is hardly possible [meaning that a correctly working and properly secure management application that fits the bill isn't likely to be created.] > The lesson I have learned from party-based SNMPv2 is that the stuff has > to be damn simple to use and that we should not rely on assistance from > tools to get the thing configured and running. Can't agree more. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From maria@xedia.com Mon Jul 20 23:55:28 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 XAA23325 for ; Mon, 20 Jul 1998 23:55:28 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id XAA13842 for ; Mon, 20 Jul 1998 23:54:40 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma013837; Mon, 20 Jul 98 23:54:36 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id XAA00821 for ; Mon, 20 Jul 1998 23:54:02 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma000702; Mon, 20 Jul 98 23:53:33 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id XAA19558; Mon, 20 Jul 1998 23:53:19 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id VAA08083 for ; Mon, 20 Jul 1998 21:53:17 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id XAA01333 for ; Mon, 20 Jul 1998 23:53:15 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma001323; Mon, 20 Jul 98 23:52:45 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id VAA03817 for ; Mon, 20 Jul 1998 21:48:45 -0400 (EDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id AAA23562 for ; Tue, 21 Jul 1998 00:27:41 -0400 (EDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id AAA28334; Tue, 21 Jul 1998 00:27:39 -0400 Received: from watpub1.watson.ibm.com (watpub1.watson.ibm.com [9.2.101.12]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id AAA12160; Tue, 21 Jul 1998 00:27:38 -0400 Received: by watpub1.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA28038; Tue, 21 Jul 1998 00:27:38 -0400 From: Uri Blumenthal Message-Id: <9807210427.AA28038@watpub1.watson.ibm.com> Subject: Re: VACM and DISMAN To: mo@UU.NET (Mike O'Dell) Date: Tue, 21 Jul 1998 00:27:37 -0400 (EDT) Cc: disman@nexen.com, snmpv3@tis.com In-Reply-To: from "Mike O'Dell" at Jul 7, 98 08:05:12 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Mike O'Dell says: > for my money (and UUNET's), we believe that time-varying > role-based security policy is the only way you deal with > humans, Yes, but are you willing to pay the performance/code-size price for the privilege of having such a policy? Plus, do you realize that the only place to keep the "decider" code is in the data owner, i.e. that "network element" which you refer to below: > ......... which is very distinct from network elements. > for example, a network operator on duty may have > significant access rights to test and reconfigure a network > element, but when the person goes off-shift, they must lose > those rights. > the only way to do this rationally is to do the mapping of > person-role-time-rights *mostly* in NMS software which sits > between the operator and the network elements. If NMS does the mapping, you (a) may lose the proper audit trail and (b) may have to restrict management operations to certain installed NMS. > the machinery in SNMPv3 supports identity-rights mappings, > and that is sufficient given the interposed NMS software > which uses a set of identities instantiated in the network > elements to map a given person performing a specific role > at a certain time into a set of required access rights. This is not a role-based Access Control. It's a role-based NMS. Now, maybe that's all that is required? -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From maria@xedia.com Tue Jul 21 06:47: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 GAA26588 for ; Tue, 21 Jul 1998 06:47:24 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id GAA25851 for ; Tue, 21 Jul 1998 06:46:35 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma025848; Tue, 21 Jul 98 06:46:33 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id GAA04904 for ; Tue, 21 Jul 1998 06:45:58 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma004864; Tue, 21 Jul 98 06:45:49 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id GAA22889; Tue, 21 Jul 1998 06:46:22 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id EAA08836 for ; Tue, 21 Jul 1998 04:46:11 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id GAA14040 for ; Tue, 21 Jul 1998 06:46:09 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma014030; Tue, 21 Jul 98 06:45:47 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id EAA08085 for ; Tue, 21 Jul 1998 04:44:17 -0400 (EDT) Received: from relay9.uu.net (relay9.uu.net [192.48.96.85]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id HAA24163 for ; Tue, 21 Jul 1998 07:23:17 -0400 (EDT) Received: from neserve0.uu.net by relay9.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQeyzd19994; Tue, 21 Jul 1998 07:23:16 -0400 (EDT) Received: from localhost by neserve0.uu.net with SMTP (peer crosschecked as: mo@localhost) id QQeyzd04121; Tue, 21 Jul 1998 07:23:16 -0400 (EDT) Message-Id: To: uri@watson.ibm.com cc: mo@UU.NET (Mike O'Dell), disman@nexen.com, snmpv3@tis.com Subject: Re: VACM and DISMAN In-reply-to: Your message of "Tue, 21 Jul 1998 00:27:37 EDT." <9807210427.AA28038@watpub1.watson.ibm.com> Date: Tue, 21 Jul 1998 07:23:15 -0400 From: "Mike O'Dell" no no no no the network element does NOT need to do the deciding -mo From maria@xedia.com Tue Jul 21 06:47: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 GAA26590 for ; Tue, 21 Jul 1998 06:47:24 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id GAA25853 for ; Tue, 21 Jul 1998 06:46:35 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma025849; Tue, 21 Jul 98 06:46:33 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id GAA04903 for ; Tue, 21 Jul 1998 06:45:58 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma004854; Tue, 21 Jul 98 06:45:47 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id GAA22876; Tue, 21 Jul 1998 06:46:19 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id EAA08834 for ; Tue, 21 Jul 1998 04:46:06 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id GAA25824 for ; Tue, 21 Jul 1998 06:46:05 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma025817; Tue, 21 Jul 98 06:45:46 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id EAA08082 for ; Tue, 21 Jul 1998 04:43:06 -0400 (EDT) Received: from relay8.uu.net (relay8.uu.net [192.48.96.84]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id HAA17383 for ; Tue, 21 Jul 1998 07:22:07 -0400 (EDT) Received: from neserve0.uu.net by relay8.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQeyzd04778; Tue, 21 Jul 1998 07:22:05 -0400 (EDT) Received: from localhost by neserve0.uu.net with SMTP (peer crosschecked as: mo@localhost) id QQeyzd04077; Tue, 21 Jul 1998 07:22:05 -0400 (EDT) Message-Id: To: uri@watson.ibm.com cc: schoenw@ibr.cs.tu-bs.de (Juergen Schoenwaelder), rpresuhn@dorothy.bmc.com, disman@nexen.com, snmpv3@tis.com Subject: Re: VACM and DISMAN In-reply-to: Your message of "Mon, 20 Jul 1998 22:31:39 EDT." <9807210231.AA30262@watpub1.watson.ibm.com> Date: Tue, 21 Jul 1998 07:22:04 -0400 From: "Mike O'Dell" doing roll-based authentication is trivial - the user authenticates FOR A SPECIFIC ROLE and then does his work under that guise. there is no magic required whereby the software has to "guess" what roll is required. there is an absolute declaration of intent by the human. jeez - why are you guys trying to hard to fail?? -mo From maria@xedia.com Tue Jul 21 11:08:04 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 LAA28650 for ; Tue, 21 Jul 1998 11:08:03 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA13486 for ; Tue, 21 Jul 1998 11:07:13 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma013475; Tue, 21 Jul 98 11:06:52 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA02893 for ; Tue, 21 Jul 1998 11:06:17 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma002519; Tue, 21 Jul 98 11:05:57 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id LAA04963; Tue, 21 Jul 1998 11:05:42 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA09629 for ; Tue, 21 Jul 1998 09:05:37 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA13379 for ; Tue, 21 Jul 1998 11:05:35 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma013236; Tue, 21 Jul 98 11:04:42 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id IAA14438 for ; Tue, 21 Jul 1998 08:55:28 -0400 (EDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id LAA25227 for ; Tue, 21 Jul 1998 11:34:31 -0400 (EDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id LAA23370; Tue, 21 Jul 1998 11:34:29 -0400 Received: from watpub1.watson.ibm.com (watpub1.watson.ibm.com [9.2.101.12]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id LAA16716; Tue, 21 Jul 1998 11:34:28 -0400 Received: by watpub1.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA45762; Tue, 21 Jul 1998 11:34:19 -0400 From: Uri Blumenthal Message-Id: <9807211534.AA45762@watpub1.watson.ibm.com> Subject: Re: VACM and DISMAN To: mo@UU.NET (Mike O'Dell) Date: Tue, 21 Jul 1998 11:34:18 -0400 (EDT) Cc: mo@UU.NET, disman@nexen.com, snmpv3@tis.com In-Reply-To: from "Mike O'Dell" at Jul 21, 98 07:23:15 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Mike O'Dell says: > no no no no > > the network element does NOT need to do the deciding In that case your idea of access control has nothing in common with that of mine. To me if the network element has the data to be accessed, then the only place where access control can be done securely is that net.element. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From maria@xedia.com Tue Jul 21 12:17: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 MAA29204 for ; Tue, 21 Jul 1998 12:17:28 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA19421 for ; Tue, 21 Jul 1998 12:16:38 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma019394; Tue, 21 Jul 98 12:16:09 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA06035 for ; Tue, 21 Jul 1998 12:15:34 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma005783; Tue, 21 Jul 98 12:15:20 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id MAA24418; Tue, 21 Jul 1998 12:15:25 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA10091 for ; Tue, 21 Jul 1998 10:15:21 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id MAA04267 for ; Tue, 21 Jul 1998 12:15:19 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma004256; Tue, 21 Jul 98 12:14:55 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id KAA16177 for ; Tue, 21 Jul 1998 10:01:44 -0400 (EDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id MAA25507 for ; Tue, 21 Jul 1998 12:40:48 -0400 (EDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id MAA17948; Tue, 21 Jul 1998 12:40:40 -0400 Received: from watpub1.watson.ibm.com (watpub1.watson.ibm.com [9.2.101.12]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id MAA14642; Tue, 21 Jul 1998 12:40:39 -0400 Received: by watpub1.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA47368; Tue, 21 Jul 1998 12:40:34 -0400 From: Uri Blumenthal Message-Id: <9807211640.AA47368@watpub1.watson.ibm.com> Subject: Re: VACM and DISMAN To: mo@UU.NET (Mike O'Dell) Date: Tue, 21 Jul 1998 12:40:33 -0400 (EDT) Cc: schoenw@ibr.cs.tu-bs.de, rpresuhn@dorothy.bmc.com, disman@nexen.com, snmpv3@tis.com In-Reply-To: from "Mike O'Dell" at Jul 21, 98 07:22:04 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Mike O'Dell says: > doing roll-based authentication is trivial - the user authenticates > FOR A SPECIFIC ROLE and then does his work under that guise. The *concept* is trivial. The implementation is not, and neither are the details. Plus, what you seem to mean is *not* a "true" role-based approach. A "true" one requires a combination of principal rights with role rights. What you seem to imply is "authenticate the principal, use the rights of the `role'". Oh, and of course one needs a "permissions" table - which principal is authorized for which roles (and maybe this table should include date/time restrictions?). It is simple until you start thinking about how people will use it, how crackers will try to break it, and what it is supposed to protect you from... [Now back to my jet-lagged uneasy sleep, going "barrel rolls" :-] > there is no magic required whereby the software has to "guess" what > roll is required. there is an absolute declaration of intent by the > human. No magic, just (a) inclusion of the role name/tag in the message and (b) decision on how to compute the access rights [to base it solely on the role "rights", or on a combination of the role "rights" and the user "rights"]. I wish you'd commented on that rather than on the triviality of the basic concept... -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From maria@xedia.com Tue Jul 21 12:54:14 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 MAA29494 for ; Tue, 21 Jul 1998 12:54:13 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA21457 for ; Tue, 21 Jul 1998 12:53:23 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma021451; Tue, 21 Jul 98 12:53:17 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA09141 for ; Tue, 21 Jul 1998 12:52:42 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma009047; Tue, 21 Jul 98 12:52:36 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id MAA04798; Tue, 21 Jul 1998 12:53:07 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA10396 for ; Tue, 21 Jul 1998 10:52:54 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA21441 for ; Tue, 21 Jul 1998 12:52:53 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma021439; Tue, 21 Jul 98 12:52:46 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id KAA17325 for ; Tue, 21 Jul 1998 10:50:10 -0400 (EDT) Received: from relay8.uu.net (relay8.uu.net [192.48.96.84]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id NAA19718 for ; Tue, 21 Jul 1998 13:29:15 -0400 (EDT) Received: from neserve0.uu.net by relay8.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQezab21922; Tue, 21 Jul 1998 13:29:14 -0400 (EDT) Received: from localhost by neserve0.uu.net with SMTP (peer crosschecked as: mo@localhost) id QQezab29696; Tue, 21 Jul 1998 13:29:13 -0400 (EDT) Message-Id: To: uri@watson.ibm.com cc: mo@UU.NET (Mike O'Dell), disman@nexen.com, snmpv3@tis.com Subject: Re: VACM and DISMAN In-reply-to: Your message of "Tue, 21 Jul 1998 11:34:18 EDT." <9807211534.AA45762@watpub1.watson.ibm.com> Date: Tue, 21 Jul 1998 13:29:13 -0400 From: "Mike O'Dell" of course you are right in the limiting case however, *all* access control need not be done in the element, especially if there are rich semantic policies needed. all you have to do is have an adequate partitioning whereby enough simple mechanisms exist in the element to allow implementation with the heavy lifting done elsewhere -mo From maria@xedia.com Tue Jul 21 13:00:08 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 NAA29546 for ; Tue, 21 Jul 1998 13:00:07 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA22027 for ; Tue, 21 Jul 1998 12:59:15 -0500 (CDT) Received: from dresden.bmc.com(198.64.253.250) by almond.bmc.com via smap (V2.0) id xma021950; Tue, 21 Jul 98 12:58:36 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA14113 for ; Tue, 21 Jul 1998 12:57:59 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma013910; Tue, 21 Jul 98 12:57:46 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id MAA06120; Tue, 21 Jul 1998 12:58:06 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA10444 for ; Tue, 21 Jul 1998 10:58:05 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id MAA06938 for ; Tue, 21 Jul 1998 12:58:03 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma006914; Tue, 21 Jul 98 12:57:37 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id KAA17448 for ; Tue, 21 Jul 1998 10:59:01 -0400 (EDT) Received: from relay9.uu.net (relay9.uu.net [192.48.96.85]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id NAA25781 for ; Tue, 21 Jul 1998 13:38:06 -0400 (EDT) Received: from neserve0.uu.net by relay9.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQezac06672; Tue, 21 Jul 1998 13:38:04 -0400 (EDT) Received: from localhost by neserve0.uu.net with SMTP (peer crosschecked as: mo@localhost) id QQezac00262; Tue, 21 Jul 1998 13:38:02 -0400 (EDT) Message-Id: To: uri@watson.ibm.com cc: mo@UU.NET (Mike O'Dell), schoenw@ibr.cs.tu-bs.de, rpresuhn@dorothy.bmc.com, disman@nexen.com, snmpv3@tis.com Subject: Re: VACM and DISMAN In-reply-to: Your message of "Tue, 21 Jul 1998 12:40:33 EDT." <9807211640.AA47368@watpub1.watson.ibm.com> Date: Tue, 21 Jul 1998 13:38:02 -0400 From: "Mike O'Dell" Uri, i've been doing OS security since the early 1970s - i don't need the lecture. you can complicate the model to the degree you wish and i'm not going to argue about what constitutes "true" role-based security. arguments like that produced the SNMPv2 success. suffice it to say that we firmly believe that the authentication and authorization capabilities we need to operate a network of over 10,000 network elements and over half a billion US$ in cost, using a "role-inspired" model, can be implemented at reasonable cost and complexity using a combination of machinery resident in the network elements and some resident in the management software infrastructure, all using SNMPv3 mechanics as currently described. now can we please just ship the damn thing so we can get on with running our network?? -mo From maria@xedia.com Tue Jul 21 13:52: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 NAA29962 for ; Tue, 21 Jul 1998 13:52:15 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA26510 for ; Tue, 21 Jul 1998 13:51:24 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma026487; Tue, 21 Jul 98 13:51:03 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA05135 for ; Tue, 21 Jul 1998 13:50:27 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma005033; Tue, 21 Jul 98 13:50:20 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id NAA22093; Tue, 21 Jul 1998 13:50:48 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA11330 for ; Tue, 21 Jul 1998 11:50:46 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id NAA10301 for ; Tue, 21 Jul 1998 13:50:31 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma010286; Tue, 21 Jul 98 13:50:06 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id LAA19057 for ; Tue, 21 Jul 1998 11:51:37 -0400 (EDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id OAA20339 for ; Tue, 21 Jul 1998 14:30:42 -0400 (EDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id OAA16928; Tue, 21 Jul 1998 14:30:34 -0400 Received: from watpub1.watson.ibm.com (watpub1.watson.ibm.com [9.2.101.12]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id OAA11824; Tue, 21 Jul 1998 14:30:33 -0400 Received: by watpub1.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA43592; Tue, 21 Jul 1998 14:30:32 -0400 From: Uri Blumenthal Message-Id: <9807211830.AA43592@watpub1.watson.ibm.com> Subject: Re: VACM and DISMAN To: mo@UU.NET (Mike O'Dell) Date: Tue, 21 Jul 1998 14:30:31 -0400 (EDT) Cc: mo@UU.NET, schoenw@ibr.cs.tu-bs.de, rpresuhn@dorothy.bmc.com, disman@nexen.com, snmpv3@tis.com In-Reply-To: from "Mike O'Dell" at Jul 21, 98 01:38:02 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Mike O'Dell says: > Uri, i've been doing OS security since the early 1970s - i don't need > the lecture. OK, I'm glad to finally find somebody who knows it all. But since I don't know it all, and in the early 70s I've been doing other things - it would be helpful if you answered the purely technical questions I asked. Besides, you can't expect a consistent reaction unless those questions are answered uniformly by every implementation. I hope it is clear? > you can complicate the model to the degree you wish and i'm not going > to argue about what constitutes "true" role-based security. arguments > like that produced the SNMPv2 success. I'm trying to figure out what the hell it is that you want, and to possibly map it onto terminology that other people use/ That's all. > suffice it to say that we firmly believe that the authentication and > authorization capabilities we need to operate a network of over 10,000 > network elements and over half a billion US$ in cost, using a > "role-inspired" model, can be implemented at reasonable cost and > complexity using a combination of machinery resident in the network > elements and some resident in the management software infrastructure, > all using SNMPv3 mechanics as currently described. Fine with me - especially if instead of this pointless and non-technical bickering you take 5 minutes to understand the technical questions I've been asking and another 5 minutes to answer them. > now can we please just ship the damn thing so we can get on with > running our network?? Who stops you from shipping "the damn thing"? Not me, I hope? -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From maria@xedia.com Tue Jul 21 13:56:22 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 NAA29993 for ; Tue, 21 Jul 1998 13:56:21 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA26645 for ; Tue, 21 Jul 1998 13:55:26 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma026621; Tue, 21 Jul 98 13:55:02 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA09255 for ; Tue, 21 Jul 1998 13:54:26 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma008884; Tue, 21 Jul 98 13:54:04 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id NAA23040; Tue, 21 Jul 1998 13:54:32 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA11343 for ; Tue, 21 Jul 1998 11:54:26 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA26597 for ; Tue, 21 Jul 1998 13:54:25 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma026580; Tue, 21 Jul 98 13:54:04 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA08229 for ; Tue, 21 Jul 1998 13:53:29 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by dresden.bmc.com via smap (3.2) id xma008029; Tue, 21 Jul 98 13:53:18 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id LAA19240 for ; Tue, 21 Jul 1998 11:59:41 -0400 (EDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id OAA20414 for ; Tue, 21 Jul 1998 14:38:46 -0400 (EDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id OAA17928; Tue, 21 Jul 1998 14:38:42 -0400 Received: from watpub1.watson.ibm.com (watpub1.watson.ibm.com [9.2.101.12]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id OAA07180; Tue, 21 Jul 1998 14:38:42 -0400 Received: by watpub1.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA43982; Tue, 21 Jul 1998 14:38:42 -0400 From: Uri Blumenthal Message-Id: <9807211838.AA43982@watpub1.watson.ibm.com> Subject: Re: VACM and DISMAN To: mo@UU.NET (Mike O'Dell) Date: Tue, 21 Jul 1998 14:38:42 -0400 (EDT) Cc: mo@UU.NET, disman@nexen.com, snmpv3@tis.com In-Reply-To: from "Mike O'Dell" at Jul 21, 98 01:29:13 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Mike O'Dell says: > however, *all* access control need not be done in the element, > especially if there are rich semantic policies needed. > all you have to do is have an adequate partitioning whereby > enough simple mechanisms exist in the element to allow > implementation with the heavy lifting done elsewhere If you have it roughly figured out, why don't you post an outline of what actions are to be taken and by what entities, when doing access control? Furnishing as many details as you can? Because at this point it sounds more like a sales pitch than a technical proposal (i.e. "simple enough", "adequate partitioning" etc. are rather subjective terms and have no meaning until you tell what exactly you want the things to look like). -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From maria@xedia.com Tue Jul 21 14:42:32 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 OAA00402 for ; Tue, 21 Jul 1998 14:42:32 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA29375 for ; Tue, 21 Jul 1998 14:41:43 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma029355; Tue, 21 Jul 98 14:41:19 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA20722 for ; Tue, 21 Jul 1998 14:40:44 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma020609; Tue, 21 Jul 98 14:40:37 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id OAA06557; Tue, 21 Jul 1998 14:40:45 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA11805 for ; Tue, 21 Jul 1998 12:40:43 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA29316 for ; Tue, 21 Jul 1998 14:40:42 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma029296; Tue, 21 Jul 98 14:40:17 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id MAA20040 for ; Tue, 21 Jul 1998 12:25:03 -0400 (EDT) Received: from relay9.uu.net (relay9.uu.net [192.48.96.85]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id PAA20600 for ; Tue, 21 Jul 1998 15:04:09 -0400 (EDT) Received: from neserve0.uu.net by relay9.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQezai21784; Tue, 21 Jul 1998 15:04:08 -0400 (EDT) Received: from localhost by neserve0.uu.net with SMTP (peer crosschecked as: mo@localhost) id QQezai09878; Tue, 21 Jul 1998 15:04:08 -0400 (EDT) Message-Id: To: uri@watson.ibm.com cc: mo@UU.NET (Mike O'Dell), disman@nexen.com, snmpv3@tis.com Subject: Re: VACM and DISMAN In-reply-to: Your message of "Tue, 21 Jul 1998 14:38:42 EDT." <9807211838.AA43982@watpub1.watson.ibm.com> Date: Tue, 21 Jul 1998 15:04:07 -0400 From: "Mike O'Dell" i don't need any more mechanism than what's already there. the management interface maps User X Role -> AccessPartition based on time, policy, presented credentials, etc. of course it keeps records of all such mappings granted as well as all activities performed after the granting. the network elements have identies for the full set of AccessPartitions (which is much smaller than User x Role) and the credentials for access via one of those partition identities is maintained *solely* by the management software, which actually performs the accesses on behalf of the authorized user in his role. the management software effectively allows a given user to take on a given role at a particular time, and all the mediation required to execute the policy is only in the management interface software. the only identities defined in the network elements are the members of equivalence classes which cover the required rights. i assume what you believe is a full "role-based model" involves doing general capability vector algebra. such models are frequently operationally incomplete as that they don't generally support time-varying policy except via exogenous mediators (which is exactly what i'm proposing), and they require the maintainence of a large amount of distributed state which is not required for this purpose. yes, i understand that what i suggest is not as general, but that's fine - "You don't need to boil the ocean just to get a poached fish." so can we please get on with getting done?? -mo From maria@xedia.com Tue Jul 21 15:16: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 PAA00672 for ; Tue, 21 Jul 1998 15:16:15 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA01426 for ; Tue, 21 Jul 1998 15:15:26 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma001416; Tue, 21 Jul 98 15:15:10 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id PAA21323 for ; Tue, 21 Jul 1998 15:14:35 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma021150; Tue, 21 Jul 98 15:14:19 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id PAA15413; Tue, 21 Jul 1998 15:14:47 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA11926 for ; Tue, 21 Jul 1998 13:14:45 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id PAA15898 for ; Tue, 21 Jul 1998 15:14:43 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma015890; Tue, 21 Jul 98 15:14:22 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id NAA23111 for ; Tue, 21 Jul 1998 13:06:24 -0400 (EDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id PAA26488 for ; Tue, 21 Jul 1998 15:45:30 -0400 (EDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id PAA13924; Tue, 21 Jul 1998 15:44:01 -0400 Received: from watpub1.watson.ibm.com (watpub1.watson.ibm.com [9.2.101.12]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id PAA18748; Tue, 21 Jul 1998 15:44:00 -0400 Received: by watpub1.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA38384; Tue, 21 Jul 1998 15:43:50 -0400 From: Uri Blumenthal Message-Id: <9807211943.AA38384@watpub1.watson.ibm.com> Subject: Re: VACM and DISMAN To: mo@UU.NET (Mike O'Dell) Date: Tue, 21 Jul 1998 15:43:49 -0400 (EDT) Cc: mo@UU.NET, disman@nexen.com, snmpv3@tis.com In-Reply-To: from "Mike O'Dell" at Jul 21, 98 03:04:07 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Mike O'Dell says: > the management interface maps User X Role -> AccessPartition > based on time, policy, presented credentials, etc. So the principal for network elements will be AccessPartition? OK by me. > the network elements have identies for the full set of > AccessPartitions (which is much smaller than User x Role) OK here. > and the credentials for access via one of those partition > identities is maintained *solely* by the management software, > which actually performs the accesses on behalf of the authorized > user in his role. Management software does not perform any access. It requests the operation to be performed (and thus the access to be granted) by the network element(s). You want the NMS to authenticate a principal and map him onto the proper group (privileges-wise, time-wise etc.)? That's doable, of course. But it means that you must come in through NMS (and not via a shell script, for example). It also means that the data owner does not have the ability to trace who did what to it. If you can live with it, so can I. > the only identities defined in the network elements are the > members of equivalence classes which cover the required rights. Fine, in light of the above. To summarize: - The "network elements" have "roles" defined as principals, with the correspondign access rights; - the NMS authenticates the users and maps the requests to the appropriate "roles"; - the network elements authenticate requests issued by the "roles"; - the NMS logs who (a user) did what, the network elements log what role did what; - the network elements share secrets with the NMS(s) only, not with the users, and thus are accessible only via NMS. Does it represent accurately what you meant? What do the others think? > i assume what you believe is a full "role-based model" > involves doing general capability vector algebra...... I believe in God and in using correct terminology - no other assumption about my beliefs is reliable (:-). I don't care whether the accepted approach is a full role-based model, a partial one, or even a remotely similar. I do care that all the i's are dotted and all the t's are crossed, when the model - whatever it is - is specified. That's all. > "You don't need to boil the ocean just to get a poached fish." > so can we please get on with getting done?? Enjoy your poached jellyfish then. [Oh, and from my prospective, we *are* done.] -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From maria@xedia.com Tue Jul 21 15:47: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 PAA00928 for ; Tue, 21 Jul 1998 15:47:53 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA03291 for ; Tue, 21 Jul 1998 15:47:02 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma003183; Tue, 21 Jul 98 15:46:32 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id PAA20262 for ; Tue, 21 Jul 1998 15:45:57 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma020019; Tue, 21 Jul 98 15:45:45 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id PAA23096; Tue, 21 Jul 1998 15:46:18 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA12029 for ; Tue, 21 Jul 1998 13:46:16 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA03128 for ; Tue, 21 Jul 1998 15:46:14 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma003071; Tue, 21 Jul 98 15:45:57 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id LAA18735 for ; Tue, 21 Jul 1998 11:34:58 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id OAA20183 for ; Tue, 21 Jul 1998 14:13:57 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA23446 for ; Tue, 21 Jul 1998 13:13:48 -0500 (CDT) Received: from dresden.bmc.com(198.64.253.250) by almond.bmc.com via smap (V2.0) id xma023408; Tue, 21 Jul 98 13:13:25 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA27715 for ; Tue, 21 Jul 1998 13:12:51 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma027621; Tue, 21 Jul 98 13:12:46 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id NAA10397 for ; Tue, 21 Jul 1998 13:13:14 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA10766 for disman@nexen.com; Tue, 21 Jul 1998 11:13:13 -0700 (PDT) Date: Tue, 21 Jul 1998 11:13:13 -0700 (PDT) From: Randy Presuhn Message-Id: <199807211813.LAA10766@dorothy.bmc.com> To: disman@nexen.com Subject: Disman in Chicago? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - If the disman working group meets in Chicago, will a single session suffice? Here are the items I think we'll need to handle: 1) possible charter updates 2) discussion of remote operations MIB (ping) if WG interest supports and addition to charter approved 3) revisions to expression / log and related MIBs 4) what to do with the (expired) framework Please post other issues to cover; the deadline for slots fast approacheth. Please inform me of slot conflicts you wish avoided. My short list: - acap - applmib - bmwg - entmib - ippm - ptopomib - rmonmib - rtfm - snmpv3 ----------------------------------------------------------------------- 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 maria@xedia.com Tue Jul 21 15:52:06 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 PAA00961 for ; Tue, 21 Jul 1998 15:52:06 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA03483 for ; Tue, 21 Jul 1998 15:51:17 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma003471; Tue, 21 Jul 98 15:51:05 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id PAA24459 for ; Tue, 21 Jul 1998 15:50:30 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma024340; Tue, 21 Jul 98 15:50:21 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id PAA24021; Tue, 21 Jul 1998 15:50:29 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA12041 for ; Tue, 21 Jul 1998 13:50:27 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id PAA18103 for ; Tue, 21 Jul 1998 15:50:25 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma018064; Tue, 21 Jul 98 15:49:52 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id NAA23974 for ; Tue, 21 Jul 1998 13:46:40 -0400 (EDT) Received: from acme.sb.west.net (acme.sb.west.net [205.254.224.2]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id QAA21130 for ; Tue, 21 Jul 1998 16:25:47 -0400 (EDT) Received: from default (pm14-15.pacificnet.net [207.171.10.48]) by acme.sb.west.net (8.9.0.Beta5/8.9.0.Beta5) with SMTP id NAA15313 for ; Tue, 21 Jul 1998 13:26:08 -0700 (PDT) Message-Id: <3.0.5.32.19980721132604.007c2100@west.net> X-Sender: mbx0024@west.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 21 Jul 1998 13:26:04 -0700 To: disman@nexen.com From: Warren Sullivan Subject: info Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" info ************************************************************* Anacapa Software -- NetScore Web based Performance Monitoring http://www.anacapa.com Tel:805-523-1745 ************************************************************* From maria@xedia.com Tue Jul 21 16:47: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 QAA01407 for ; Tue, 21 Jul 1998 16:47:35 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA07158 for ; Tue, 21 Jul 1998 16:46:37 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma007098; Tue, 21 Jul 98 16:45:57 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA14076 for ; Tue, 21 Jul 1998 16:45:19 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma013572; Tue, 21 Jul 98 16:44:20 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA08390; Tue, 21 Jul 1998 16:44:49 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA12440 for ; Tue, 21 Jul 1998 14:44:42 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA06997 for ; Tue, 21 Jul 1998 16:44:38 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma006942; Tue, 21 Jul 98 16:44:23 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id OAA25551 for ; Tue, 21 Jul 1998 14:37:51 -0400 (EDT) Received: from relay9.uu.net (relay9.uu.net [192.48.96.85]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id RAA21498 for ; Tue, 21 Jul 1998 17:16:57 -0400 (EDT) Received: from neserve0.uu.net by relay9.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQezar16496; Tue, 21 Jul 1998 17:16:55 -0400 (EDT) Received: from localhost by neserve0.uu.net with SMTP (peer crosschecked as: mo@localhost) id QQezar21092; Tue, 21 Jul 1998 17:16:54 -0400 (EDT) Message-Id: To: uri@watson.ibm.com cc: mo@UU.NET (Mike O'Dell), disman@nexen.com, snmpv3@tis.com, mo@UU.NET Subject: Re: VACM and DISMAN In-reply-to: Your message of "Tue, 21 Jul 1998 15:43:49 EDT." <9807211943.AA38384@watpub1.watson.ibm.com> Date: Tue, 21 Jul 1998 17:16:54 -0400 From: "Mike O'Dell" as for what I believe, "I believe I'll have another beer." cheers -mo From maria@xedia.com Wed Jul 22 07:58: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 HAA08682 for ; Wed, 22 Jul 1998 07:58:38 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id HAA04032 for ; Wed, 22 Jul 1998 07:57:47 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma004018; Wed, 22 Jul 98 07:57:18 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id HAA29825 for ; Wed, 22 Jul 1998 07:56:43 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma029803; Wed, 22 Jul 98 07:56:40 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id HAA23434; Wed, 22 Jul 1998 07:57:14 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id FAA17086 for ; Wed, 22 Jul 1998 05:56:48 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id HAA04009 for ; Wed, 22 Jul 1998 07:56:47 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma004001; Wed, 22 Jul 98 07:56:39 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id FAA07696 for ; Wed, 22 Jul 1998 05:48:38 -0400 (EDT) Received: from concord.com (concord.com [192.124.15.3]) by guelah.nexen.com (8.8.5/8.7.3) with SMTP id IAA28835 for ; Wed, 22 Jul 1998 08:27:55 -0400 (EDT) Received: from marvin.concord.com by concord.com (4.1/SMI-4.1) id AA07023; Wed, 22 Jul 98 08:27:46 EDT Received: from skywalker by marvin.concord.com (SMI-8.6/SMI-SVR4) id IAA23571; Wed, 22 Jul 1998 08:27:40 -0400 Message-Id: <3.0.3.32.19980722082808.0098ee10@marvin.concord.com> X-Sender: engel@marvin.concord.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 22 Jul 1998 08:28:08 -0400 To: uri@watson.ibm.com, mo@UU.NET (Mike O'Dell) From: Fred Engel Subject: Re: VACM and DISMAN Cc: mo@UU.NET, schoenw@ibr.cs.tu-bs.de, rpresuhn@dorothy.bmc.com, disman@nexen.com, snmpv3@tis.com In-Reply-To: <9807211830.AA43592@watpub1.watson.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Guys, let's not get personal :-)!! Fred At 02:30 PM 7/21/98 -0400, Uri Blumenthal wrote: >Mike O'Dell says: >> Uri, i've been doing OS security since the early 1970s - i don't need >> the lecture. > >OK, I'm glad to finally find somebody who knows it all. > >But since I don't know it all, and in the early 70s I've been doing >other things - it would be helpful if you answered the purely >technical questions I asked. Besides, you can't expect a >consistent reaction unless those questions are answered >uniformly by every implementation. I hope it is clear? > >> you can complicate the model to the degree you wish and i'm not going >> to argue about what constitutes "true" role-based security. arguments >> like that produced the SNMPv2 success. > >I'm trying to figure out what the hell it is that you want, and to >possibly map it onto terminology that other people use/ That's all. > >> suffice it to say that we firmly believe that the authentication and >> authorization capabilities we need to operate a network of over 10,000 >> network elements and over half a billion US$ in cost, using a >> "role-inspired" model, can be implemented at reasonable cost and >> complexity using a combination of machinery resident in the network >> elements and some resident in the management software infrastructure, >> all using SNMPv3 mechanics as currently described. > >Fine with me - especially if instead of this pointless and non-technical >bickering you take 5 minutes to understand the technical questions I've >been asking and another 5 minutes to answer them. > >> now can we please just ship the damn thing so we can get on with >> running our network?? > >Who stops you from shipping "the damn thing"? Not me, I hope? >-- >Regards, >Uri uri@watson.ibm.com >-=-=-=-=-=-=- > > > Fred Engel Vice President, Engineering Concord Communications, Inc. Marlboro, MA. 01752 (508)-460-4646 From maria@xedia.com Wed Jul 22 12:10: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 MAA10665 for ; Wed, 22 Jul 1998 12:10:25 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA22849 for ; Wed, 22 Jul 1998 12:09:32 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma022807; Wed, 22 Jul 98 12:09:15 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA09739 for ; Wed, 22 Jul 1998 12:08:39 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma009257; Wed, 22 Jul 98 12:08:11 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id MAA16683; Wed, 22 Jul 1998 12:08:44 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA18183 for ; Wed, 22 Jul 1998 10:08:37 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id MAA13754 for ; Wed, 22 Jul 1998 12:08:31 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma013730; Wed, 22 Jul 98 12:08:12 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id JAA14098 for ; Wed, 22 Jul 1998 09:44:09 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id MAA02060 for ; Wed, 22 Jul 1998 12:23:27 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA19136 for ; Wed, 22 Jul 1998 11:23:24 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma019116; Wed, 22 Jul 98 11:23:07 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA25309 for ; Wed, 22 Jul 1998 11:22:32 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma024928; Wed, 22 Jul 98 11:22:13 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id LAA02611; Wed, 22 Jul 1998 11:22:41 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA17743; Wed, 22 Jul 1998 09:22:41 -0700 (PDT) Date: Wed, 22 Jul 1998 09:22:41 -0700 (PDT) From: Randy Presuhn Message-Id: <199807221622.JAA17743@dorothy.bmc.com> To: disman@nexen.com, snmpv3@tis.com Subject: Re: VACM and DISMAN Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - Since there seems to be virtually no disman-specific content in this thread, I suggest limiting its continuation to the snmpv3@tis.com list. ----------------------------------------------------------------------- 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 maria@xedia.com Wed Jul 22 12:46:27 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 MAA10953 for ; Wed, 22 Jul 1998 12:46:26 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA24651 for ; Wed, 22 Jul 1998 12:45:35 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma024638; Wed, 22 Jul 98 12:45:08 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA12344 for ; Wed, 22 Jul 1998 12:44:34 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma011885; Wed, 22 Jul 98 12:44:06 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id MAA26579; Wed, 22 Jul 1998 12:44:38 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA18427 for ; Wed, 22 Jul 1998 10:44:36 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA24624 for ; Wed, 22 Jul 1998 12:44:35 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma024613; Wed, 22 Jul 98 12:44:16 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id KAA16198 for ; Wed, 22 Jul 1998 10:32:44 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id NAA04304 for ; Wed, 22 Jul 1998 13:11:59 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA23029 for ; Wed, 22 Jul 1998 12:11:52 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma023016; Wed, 22 Jul 98 12:11:36 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA11898 for ; Wed, 22 Jul 1998 12:11:01 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma011743; Wed, 22 Jul 98 12:10:52 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id MAA17466; Wed, 22 Jul 1998 12:11:12 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA18196; Wed, 22 Jul 1998 10:10:46 -0700 (PDT) Date: Wed, 22 Jul 1998 10:10:46 -0700 (PDT) From: Randy Presuhn Message-Id: <199807221710.KAA18196@dorothy.bmc.com> To: Harald.Alvestrand@maxware.no, wijnen@VNET.IBM.COM Subject: Request for disman meeting slot Cc: agenda@ietf.org, disman@nexen.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > Date: Mon, 6 Jul 1998 15:16:20 -0400 > Message-Id: <199807061916.PAA27950@ietf.org> > Subject: 42nd IETF-CHICAGO, IL: SCHEDULING > To: wgchairs@ietf.org, bofchairs@ietf.org > From: agenda@ietf.org ... > 1. All scheduling requests must be sent to the appropriate Area > Director(s) with a copy to: agenda@ietf.org ... > Operations: , ... Done (with this message). > > a. Working Group or BOF name. (Please read the BOF Procedure at > ftp://ftp.ietf.org/ietf/1bof-procedures.txt > before requesting a slot for a BOF.) disman > b. Area under which Working Group (or BOF) appears; Operations > c. Conflicts you wish to avoid, please be as specific as possible. > You will be notified of any conflicts which arise. Conflicts > should then be resolved by the Chairs and the final outcome > sent to: agenda@ietf.org We wish to avoid conflicts with: HMIB or HMEDIA (name uncertain) BOF on H.32x mibs acap agentx applmib bmwg bridge entmib hubmib ippm opsarea ptopomib rmonmib rtfm snmpv3 > d. Expected Attendance; estimate 60 attendees based on attendance from previous meeting. > e. Any special requests. i.e., do you want your session multicast > (multicast slots cannot always be guaranteed). None. > 2. Tuesday will have one-hour sessions. If your working group or BOF > needs to meet for one hour or less it will be scheduled on Tuesday. > Please indicate on your request if you will need a one-hour session. > Requests for two contiguous one-hour sessions will not be addressed > until all one-hour requests have been accommodated. We do not need a one-hour session. > 3. Working groups will be allowed a maximum of two slots. If your > working group will need more, please let me know. You will get > additional slots only if they are available after agenda scheduling > has closed (currently August 3) and with approval from the AD. ... We need one two-hour session. ----------------------------------------------------------------------- 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 maria@xedia.com Thu Jul 23 11:52:44 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 LAA22010 for ; Thu, 23 Jul 1998 11:52:39 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA19510 for ; Thu, 23 Jul 1998 11:51:45 -0500 (CDT) Received: from dresden.bmc.com(198.64.253.250) by almond.bmc.com via smap (V2.0) id xma019378; Thu, 23 Jul 98 11:51:20 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA10632 for ; Thu, 23 Jul 1998 11:50:44 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma010475; Thu, 23 Jul 98 11:50:37 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id LAA24226; Thu, 23 Jul 1998 11:51:10 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA24755 for ; Thu, 23 Jul 1998 09:50:56 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id LAA21459 for ; Thu, 23 Jul 1998 11:50:49 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma021454; Thu, 23 Jul 98 11:50:41 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id JAA13569 for ; Thu, 23 Jul 1998 09:33:34 -0400 (EDT) Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id MAA05467 for ; Thu, 23 Jul 1998 12:13:09 -0400 (EDT) Received: from henkell.ibr.cs.tu-bs.de (henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.1/8.9.0) with ESMTP id SAA25632; Thu, 23 Jul 1998 18:13:03 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id SAA08702; Thu, 23 Jul 1998 18:12:58 +0200 Date: Thu, 23 Jul 1998 18:12:58 +0200 Message-Id: <199807231612.SAA08702@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: rpresuhn@dorothy.bmc.com CC: disman@nexen.com In-reply-to: <199807211813.LAA10766@dorothy.bmc.com> (message from Randy Presuhn on Tue, 21 Jul 1998 11:13:13 -0700 (PDT)) Subject: Re: Disman in Chicago? References: <199807211813.LAA10766@dorothy.bmc.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII >>>>> Randy Presuhn writes: Randy> Please post other issues to cover; the deadline for slots fast Randy> approacheth. Our implementation of the Script MIB uses what we call the "Script MIB Extensibility" protocol (SMX). It separates the runtime systems (e.g. a Java virtual machine or a Tcl interpreter) from the Script MIB SNMP agent. This allows to support new languages and runtime systems with little cost as most of the complexity is not visible by the runtime systems. The current draft version of our protocol definition is available at http://www.ibr.cs.tu-bs.de/projects/jasmin/smx.ps. We expect to have the final version done in August. I would like to know whether there is any WG interest in SMX. If yes, we would be happy to discuss and revise the SMX definition and to publish them as a WG result. Juergen Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3289) From maria@xedia.com Fri Jul 24 10:47: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 KAA03114 for ; Fri, 24 Jul 1998 10:47:22 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA08690 for ; Fri, 24 Jul 1998 10:46:25 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma007986; Fri, 24 Jul 98 10:44:16 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id KAA03162 for ; Fri, 24 Jul 1998 10:43:41 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma003064; Fri, 24 Jul 98 10:43:34 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id KAA00737; Fri, 24 Jul 1998 10:43:54 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA27728 for ; Fri, 24 Jul 1998 08:43:29 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id GAA28279 for ; Fri, 24 Jul 1998 06:25:36 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma028272; Fri, 24 Jul 98 06:25:16 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id GAA10170 for ; Fri, 24 Jul 1998 06:51:38 -0400 (EDT) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by nexen.nexen.com (8.8.5/8.7.3) with SMTP id GAA01470 for ; Fri, 24 Jul 1998 06:51:36 -0400 (EDT) Received: from myrtilos.cs.utwente.nl by utrhcs.cs.utwente.nl (SMI-8.6/csmajor-1.5-RBCS) id MAA09981; Fri, 24 Jul 1998 12:51:33 +0200 Received: from cs.utwente.nl by myrtilos.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id MAA28177; Fri, 24 Jul 1998 12:51:32 +0200 Message-ID: <35B866BB.826BD26B@cs.utwente.nl> Date: Fri, 24 Jul 1998 12:49:31 +0200 From: Ron Sprenkels Organization: C.T.I.T. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Juergen Schoenwaelder CC: disman@nexen.com Subject: Example in section 5.3 of draft-ietf-disman-schedule-mib-04.txt References: <199807201823.UAA04226@henkell.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Juergen, I believe the words 'monday' and 'friday' should be swapped in the example of section 5.3 of the the schedule-mib-04.txt document. > 5.3. Turning an interface off during weekends > > The scheduling entry which brings the interface down on every Friday > evening [...] > > schedWeekDay.3.98.111.98.6.105.102.45.111.102.102 = { monday } > ^^^^^^ > > The scheduling entry which brings the interface up on every Monday > morning [...] > > schedWeekDay.3.98.111.98.5.105.102.45.111.110 = { friday } > ^^^^^^ regards, Ron. -------------------------------------------------------------------------- Ron Sprenkels sprenkel@cs.utwente.nl http://www.cs.utwente.nl/~sprenkel University of Twente, Department of Computer Science, TSS Management group P.O. Box 217, 7500 AE Enschede, The Netherlands. (Tel. +31 53 489 4663) From maria@xedia.com Fri Jul 24 10:55:01 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 KAA03180 for ; Fri, 24 Jul 1998 10:55:01 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA10766 for ; Fri, 24 Jul 1998 10:54:05 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma009646; Fri, 24 Jul 98 10:49:56 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id KAA08782 for ; Fri, 24 Jul 1998 10:49:20 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma008345; Fri, 24 Jul 98 10:48:51 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id KAA02399; Fri, 24 Jul 1998 10:49:23 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA27779 for ; Fri, 24 Jul 1998 08:49:18 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id IAA13160 for ; Fri, 24 Jul 1998 08:05:15 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma013136; Fri, 24 Jul 98 08:04:43 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id IAA11610 for ; Fri, 24 Jul 1998 08:33:58 -0400 (EDT) Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id IAA02344 for ; Fri, 24 Jul 1998 08:33:56 -0400 (EDT) Received: from henkell.ibr.cs.tu-bs.de (henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.1/8.9.0) with ESMTP id OAA06956; Fri, 24 Jul 1998 14:33:49 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id OAA23336; Fri, 24 Jul 1998 14:33:49 +0200 Date: Fri, 24 Jul 1998 14:33:49 +0200 Message-Id: <199807241233.OAA23336@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: sprenkel@cs.utwente.nl CC: disman@nexen.com In-reply-to: <35B866BB.826BD26B@cs.utwente.nl> (message from Ron Sprenkels on Fri, 24 Jul 1998 12:49:31 +0200) Subject: Re: Example in section 5.3 of draft-ietf-disman-schedule-mib-04.txt References: <199807201823.UAA04226@henkell.ibr.cs.tu-bs.de> <35B866BB.826BD26B@cs.utwente.nl> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII >>>>> Ron Sprenkels writes: Ron> I believe the words 'monday' and 'friday' should be swapped in Ron> the example of section 5.3 of the the schedule-mib-04.txt Ron> document. Thanks Ron, I agree that this should be fixed. Juergen Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3289) From maria@xedia.com Fri Jul 24 12:10:14 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 MAA03786 for ; Fri, 24 Jul 1998 12:10:14 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA16304 for ; Fri, 24 Jul 1998 12:09:18 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma016297; Fri, 24 Jul 98 12:08:58 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA14684 for ; Fri, 24 Jul 1998 12:08:24 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma014615; Fri, 24 Jul 98 12:08:18 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id MAA25555; Fri, 24 Jul 1998 12:08:51 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA28439 for ; Fri, 24 Jul 1998 10:08:49 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA16294 for ; Fri, 24 Jul 1998 12:08:48 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma016281; Fri, 24 Jul 98 12:08:22 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id MAA19570 for ; Fri, 24 Jul 1998 12:38:47 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id MAA03726 for ; Fri, 24 Jul 1998 12:38:45 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA14714 for ; Fri, 24 Jul 1998 11:38:44 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma014679; Fri, 24 Jul 98 11:38:15 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA22068 for ; Fri, 24 Jul 1998 11:37:40 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma021756; Fri, 24 Jul 98 11:37:21 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id LAA17094 for ; Fri, 24 Jul 1998 11:37:45 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA28310 for disman@nexen.com; Fri, 24 Jul 1998 09:37:19 -0700 (PDT) Date: Fri, 24 Jul 1998 09:37:19 -0700 (PDT) From: Randy Presuhn Message-Id: <199807241637.JAA28310@dorothy.bmc.com> To: disman@nexen.com Subject: Disman meeting slot Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - fwd fyi. > Date: Thu, 23 Jul 1998 16:59:51 -0400 > To: Randy Presuhn > From: Marcia Beaulieu > Subject: 42nd IETF-CHICAGO, IL: DISMAN > Cc: Harald.Alvestrand@maxware.no, wijnen@vnet.ibm.com > > This is to confirm one session for DISMAN as follows: > > Thursday, August 27 at 0900-1130 > other groups scheduled at that time: ssh, mailrev, rps, fax, pkix, > avt, ipngwg > > Please submit an agenda (to agenda@ietf.org) for this meeting as soon as > possible. > > Thanks, > > Marcia > > ********************************************************************** > Marcia Beaulieu > Meeting Coordinator > Voice: 703-620-8990 ext. 210 > Fax: 703-620-9071 ----------------------------------------------------------------------- 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 maria@xedia.com Fri Jul 24 13:57: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 NAA04639 for ; Fri, 24 Jul 1998 13:57:45 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA21376 for ; Fri, 24 Jul 1998 13:56:49 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma021372; Fri, 24 Jul 98 13:56:43 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA18497 for ; Fri, 24 Jul 1998 13:56:08 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma018209; Fri, 24 Jul 98 13:55:52 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id NAA22224; Fri, 24 Jul 1998 13:56:25 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA29026 for ; Fri, 24 Jul 1998 11:56:23 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id NAA05495 for ; Fri, 24 Jul 1998 13:56:21 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma005485; Fri, 24 Jul 98 13:56:08 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id OAA22636 for ; Fri, 24 Jul 1998 14:29:03 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id OAA04483 for ; Fri, 24 Jul 1998 14:29:02 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA22404; Fri, 24 Jul 1998 14:28:59 -0400 (EDT) Message-Id: <199807241828.OAA22404@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@nexen.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-disman-notif-log-mib-02.txt Date: Fri, 24 Jul 1998 14:28:58 -0400 Sender: cclark@ns.cnri.reston.va.us --NextPart NOTE: This announcement is being re-sent with a correction made. A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Notification Log MIB Author(s) : B. Stewart Filename : draft-ietf-disman-notif-log-mib-02.txt Pages : 15 Date : 13-Mar-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 managed objects used for managing SNMP notifications. 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-disman-notif-log-mib-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-disman-notif-log-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-disman-notif-log-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: <19980723120835.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-notif-log-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-notif-log-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980723120835.I-D@ietf.org> --OtherAccess-- --NextPart-- From maria@xedia.com Fri Jul 24 14:00:11 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 OAA04687 for ; Fri, 24 Jul 1998 14:00:10 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA21619 for ; Fri, 24 Jul 1998 13:59:14 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma021558; Fri, 24 Jul 98 13:58:59 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA20768 for ; Fri, 24 Jul 1998 13:58:24 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma020461; Fri, 24 Jul 98 13:58:03 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id NAA22716; Fri, 24 Jul 1998 13:58:36 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA29036 for ; Fri, 24 Jul 1998 11:58:34 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA21534 for ; Fri, 24 Jul 1998 13:58:33 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma021463; Fri, 24 Jul 98 13:58:07 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id OAA22701 for ; Fri, 24 Jul 1998 14:30:30 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id OAA10697 for ; Fri, 24 Jul 1998 14:30:26 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA22556; Fri, 24 Jul 1998 14:30:22 -0400 (EDT) Message-Id: <199807241830.OAA22556@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@nexen.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-disman-schedule-mib-04.txt Date: Fri, 24 Jul 1998 14:30:22 -0400 Sender: cclark@ns.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 Distributed Management Working Group of the IETF. Title : Definitions of Managed Objects for Scheduling Management Operations Author(s) : D. Levi, J. Schoenwaelder Filename : draft-ietf-disman-schedule-mib-04.txt Pages : 26 Date : 23-Jul-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 a set of managed objects that are used to schedule management operations periodically or at specified dates and times. 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-disman-schedule-mib-04.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-disman-schedule-mib-04.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-disman-schedule-mib-04.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: <19980723165057.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-schedule-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-schedule-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980723165057.I-D@ietf.org> --OtherAccess-- --NextPart-- From maria@xedia.com Fri Jul 24 14:02: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 OAA04701 for ; Fri, 24 Jul 1998 14:02:15 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA21745 for ; Fri, 24 Jul 1998 14:01:19 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma021727; Fri, 24 Jul 98 14:01:03 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA22943 for ; Fri, 24 Jul 1998 14:00:27 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma022832; Fri, 24 Jul 98 14:00:22 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id OAA23526; Fri, 24 Jul 1998 14:00:53 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA29042 for ; Fri, 24 Jul 1998 12:00:52 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id OAA05845 for ; Fri, 24 Jul 1998 14:00:50 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma005804; Fri, 24 Jul 98 14:00:23 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id OAA22698 for ; Fri, 24 Jul 1998 14:30:22 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id OAA10693 for ; Fri, 24 Jul 1998 14:30:20 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA22541; Fri, 24 Jul 1998 14:30:15 -0400 (EDT) Message-Id: <199807241830.OAA22541@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@nexen.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-disman-script-mib-05.txt Date: Fri, 24 Jul 1998 14:30:15 -0400 Sender: cclark@ns.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 Distributed Management Working Group of the IETF. Title : Definitions of Managed Objects for the Delegation of Management Scripts Author(s) : D. Levi, J. Schoenwaelder Filename : draft-ietf-disman-script-mib-05.txt Pages : 64 Date : 23-Jul-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 a set of managed objects that allow the delegation of management scripts to distributed managers. 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-disman-script-mib-05.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-disman-script-mib-05.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-disman-script-mib-05.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: <19980723164815.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-script-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-script-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980723164815.I-D@ietf.org> --OtherAccess-- --NextPart-- From maria@xedia.com Fri Jul 24 19:06:10 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 TAA07126 for ; Fri, 24 Jul 1998 19:06:10 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id TAA05470 for ; Fri, 24 Jul 1998 19:05:13 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma005458; Fri, 24 Jul 98 19:04:52 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id TAA27006 for ; Fri, 24 Jul 1998 19:04:17 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma026906; Fri, 24 Jul 98 19:03:54 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id TAA04989; Fri, 24 Jul 1998 19:04:27 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id RAA01275 for ; Fri, 24 Jul 1998 17:04:14 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id TAA05442 for ; Fri, 24 Jul 1998 19:04:13 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma005432; Fri, 24 Jul 98 19:03:54 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id TAA28649 for ; Fri, 24 Jul 1998 19:38:05 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id TAA06150 for ; Fri, 24 Jul 1998 19:38:04 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id SAA04737 for ; Fri, 24 Jul 1998 18:38:03 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma004726; Fri, 24 Jul 98 18:37:49 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id SAA20769 for ; Fri, 24 Jul 1998 18:37:15 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma020722; Fri, 24 Jul 98 18:37:01 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id SAA00266 for ; Fri, 24 Jul 1998 18:37:34 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA00990 for disman@nexen.com; Fri, 24 Jul 1998 16:37:33 -0700 (PDT) Date: Fri, 24 Jul 1998 16:37:33 -0700 (PDT) From: Randy Presuhn Message-Id: <199807242337.QAA00990@dorothy.bmc.com> To: disman@nexen.com Subject: disman log mib Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - A big thank-you to Bob Stewart for getting this out. Folks: please review and post your comments to this list. ----------------------------------------------------------------------- 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 adm@ietf.org Fri Jul 24 13:01:43 PDT 1998 > To: IETF-Announce: ; > Cc: disman@NEXEN.COM > From: Internet-Drafts@ietf.org > Reply-to: Internet-Drafts@ietf.org > Subject: I-D ACTION:draft-ietf-disman-notif-log-mib-02.txt > Date: Fri, 24 Jul 1998 14:28:58 -0400 > > --NextPart > > > NOTE: This announcement is being re-sent with a correction made. > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Distributed Management Working Group of the IETF. > > Title : Notification Log MIB > Author(s) : B. Stewart > Filename : draft-ietf-disman-notif-log-mib-02.txt > Pages : 15 > Date : 13-Mar-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 managed > objects used for managing SNMP notifications. > > 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-disman-notif-log-mib-02.txt". > A URL for the Internet-Draft is: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-disman-notif-log-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-disman-notif-log-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: <19980723120835.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-ietf-disman-notif-log-mib-02.txt > > --OtherAccess > Content-Type: Message/External-body; > name="draft-ietf-disman-notif-log-mib-02.txt"; > site="ftp.ietf.org"; > access-type="anon-ftp"; > directory="internet-drafts" > > Content-Type: text/plain > Content-ID: <19980723120835.I-D@ietf.org> > > --OtherAccess-- > > --NextPart-- > > > From maria@xedia.com Sat Jul 25 06:33:53 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 GAA01315 for ; Sat, 25 Jul 1998 06:33:53 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id GAA02169 for ; Sat, 25 Jul 1998 06:32:54 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma002167; Sat, 25 Jul 98 06:32:38 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id GAA18321 for ; Sat, 25 Jul 1998 06:32:03 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma018294; Sat, 25 Jul 98 06:31:47 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id GAA21701; Sat, 25 Jul 1998 06:32:21 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id EAA03748 for ; Sat, 25 Jul 1998 04:32:07 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id GAA06909 for ; Sat, 25 Jul 1998 06:32:05 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma006891; Sat, 25 Jul 98 06:31:47 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id HAA05240 for ; Sat, 25 Jul 1998 07:06:26 -0400 (EDT) Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id HAA12572 for ; Sat, 25 Jul 1998 07:06:25 -0400 (EDT) Received: from henkell.ibr.cs.tu-bs.de (henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.1/8.9.0) with ESMTP id NAA18008; Sat, 25 Jul 1998 13:06:23 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id NAA05932; Sat, 25 Jul 1998 13:06:22 +0200 Date: Sat, 25 Jul 1998 13:06:22 +0200 Message-Id: <199807251106.NAA05932@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: rpresuhn@dorothy.bmc.com CC: disman@nexen.com In-reply-to: <199807242337.QAA00990@dorothy.bmc.com> (message from Randy Presuhn on Fri, 24 Jul 1998 16:37:33 -0700 (PDT)) Subject: Re: disman log mib References: <199807242337.QAA00990@dorothy.bmc.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII >>>>> Randy Presuhn writes: Randy> A big thank-you to Bob Stewart for getting this out. Folks: Randy> please review and post your comments to this list. This is *not* a new draft: >>>>> Internet-Drafts@ietf.org wrote: ID> NOTE: This announcement is being re-sent with a correction made. draft-ietf-disman-notif-log-mib-02.txt has been around since March. I grabbed a new version from ftp.ietf.org and there is no difference between the March version and the newly announced version (except a few white space changes). So, instead of re-reading an old version, you might want to study the documents under WG last call. ;-) Juergen Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3289) From maria@xedia.com Mon Jul 27 12:10: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 MAA26243 for ; Mon, 27 Jul 1998 12:10:47 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA03202 for ; Mon, 27 Jul 1998 12:09:44 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma003192; Mon, 27 Jul 98 12:09:17 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA16161 for ; Mon, 27 Jul 1998 12:08:42 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma016082; Mon, 27 Jul 98 12:08:36 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id MAA26814; Mon, 27 Jul 1998 12:09:10 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA09263 for ; Mon, 27 Jul 1998 10:08:45 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA03157 for ; Mon, 27 Jul 1998 12:08:43 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma003143; Mon, 27 Jul 98 12:08:19 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id MAA09145 for ; Mon, 27 Jul 1998 12:21:03 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id MAA16367 for ; Mon, 27 Jul 1998 12:20:43 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA00021 for ; Mon, 27 Jul 1998 11:20:38 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma000017; Mon, 27 Jul 98 11:20:30 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA00232 for ; Mon, 27 Jul 1998 11:19:55 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma029977; Mon, 27 Jul 98 11:19:47 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id LAA11449 for ; Mon, 27 Jul 1998 11:20:18 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA08810 for disman@nexen.com; Mon, 27 Jul 1998 09:19:52 -0700 (PDT) Date: Mon, 27 Jul 1998 09:19:52 -0700 (PDT) From: Randy Presuhn Message-Id: <199807271619.JAA08810@dorothy.bmc.com> To: disman@nexen.com Subject: Re: disman log mib Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > Date: Sat, 25 Jul 1998 13:06:22 +0200 > From: Juergen Schoenwaelder > To: rpresuhn@dorothy.bmc.com > CC: disman@nexen.com > Subject: Re: disman log mib ... > Randy> A big thank-you to Bob Stewart for getting this out. Folks: > Randy> please review and post your comments to this list. > > This is *not* a new draft: ... Oops. Shortly before the announcement appeared, Bob had said he'd be getting some updated drafts out. I should have known that the turnaround time was too good to be true. Bob: you're not off the hook yet! :-) ----------------------------------------------------------------------- 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 maria@xedia.com Wed Jul 29 17:00: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 RAA22635 for ; Wed, 29 Jul 1998 17:00:51 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA24852 for ; Wed, 29 Jul 1998 16:59:44 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma024839; Wed, 29 Jul 98 16:59:23 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA17950 for ; Wed, 29 Jul 1998 16:58:48 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma017737; Wed, 29 Jul 98 16:58:35 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA23171; Wed, 29 Jul 1998 16:58:44 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA29239 for ; Wed, 29 Jul 1998 14:58:42 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id QAA05054 for ; Wed, 29 Jul 1998 16:58:38 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma005008; Wed, 29 Jul 98 16:58:18 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id RAA13559 for ; Wed, 29 Jul 1998 17:19:52 -0400 (EDT) Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id RAA03562 for ; Wed, 29 Jul 1998 17:19:48 -0400 (EDT) Received: from tootsie.cisco.com (tootsie.cisco.com [171.69.128.44]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with SMTP id OAA15497 for ; Wed, 29 Jul 1998 14:19:43 -0700 (PDT) Message-Id: <3.0.5.32.19980729171941.00843390@zipper.cisco.com> X-Sender: bstewart@zipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 29 Jul 1998 17:19:41 -0400 To: Distributed Management WG From: Bob Stewart Subject: Context in Notification Logging MIB Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" I'm working on getting my three MIBs out as soon as I can and no later than the Internet Draft deadline for the August IETF, so any issues I raise need prompt feedback. Juergen asked how context applies to the Notification Log MIB. Got me. My most stable thoughts on that subject so far: For the degenerate case of one SNMP engine and one context the MIB should be as simple as possible, adding complexity only where needed. What engines and contexts are included in an instantiation of the MIB should depend on the implementation. A truly mighty implementation may allow full configuration from log per context per engine to any combination. A reasonable implementation may allow much less and may default to the simplest case where the MIB is replicated in each context of each engine. Any implementation may hard-code its configuration. I don't propose to provide any objects for setting or detecting configuration other than as described below. Other than saying this in the prose section of the MIB document, the only effect I see as necessary in the MIB is to add two columns to the table that records notifications, one for contextEngineId and one for contextName. The objects in these columns are not instantiated if not applicable, so for the simplest case they don't show up. For a single-engine, multiple context instance of the MIB, the contextName column appears but the contextEngineId column doesn't. How's that sound? Bob From maria@xedia.com Thu Jul 30 03:07: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 DAA27707 for ; Thu, 30 Jul 1998 03:07:45 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id DAA22053 for ; Thu, 30 Jul 1998 03:06:37 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma022041; Thu, 30 Jul 98 03:06:16 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id DAA10457 for ; Thu, 30 Jul 1998 03:05:39 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma010325; Thu, 30 Jul 98 03:05:11 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id DAA01710; Thu, 30 Jul 1998 03:05:32 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id BAA03910 for ; Thu, 30 Jul 1998 01:05:07 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id DAA21966 for ; Thu, 30 Jul 1998 03:05:05 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma021950; Thu, 30 Jul 98 03:04:49 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id DAA19849 for ; Thu, 30 Jul 1998 03:33:22 -0400 (EDT) Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id DAA07057 for ; Thu, 30 Jul 1998 03:33:21 -0400 (EDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.1/8.9.0) with ESMTP id JAA27010; Thu, 30 Jul 1998 09:32:56 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id JAA12765; Thu, 30 Jul 1998 09:32:54 +0200 Date: Thu, 30 Jul 1998 09:32:54 +0200 Message-Id: <199807300732.JAA12765@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: bstewart@cisco.com CC: disman@nexen.com In-reply-to: <3.0.5.32.19980729171941.00843390@zipper.cisco.com> (message from Bob Stewart on Wed, 29 Jul 1998 17:19:41 -0400) Subject: Re: Context in Notification Logging MIB References: <3.0.5.32.19980729171941.00843390@zipper.cisco.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII >>>>> Bob Stewart writes: Bob> Other than saying this in the prose section of the MIB document, Bob> the only effect I see as necessary in the MIB is to add two Bob> columns to the table that records notifications, one for Bob> contextEngineId and one for contextName. The objects in these Bob> columns are not instantiated if not applicable, so for the Bob> simplest case they don't show up. For a single-engine, multiple Bob> context instance of the MIB, the contextName column appears but Bob> the contextEngineId column doesn't. I think the addition of contextEngineId and contextName is fine. However, I am a bit confused about the intention expressed in section 3 in says: > This MIB provides infrastructure for other MIBs in the form of a > local logging function. It is intended strictly for senders of > notifications. This being part of the "distributed management" WG, I would like to see this MIB written so that you can also use it to log notifications received from other devices in addition to notifications originated at the local SNMP engine. Having contextEngineId and contextName columns in the nlmLogTable makes this possible. Am I breaking the rules if I implement this MIB to log notifications from remote devices? What about replacing the second sentence cited above with different compliance statements? Juergen Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3289) From maria@xedia.com Thu Jul 30 08:05: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 IAA00163 for ; Thu, 30 Jul 1998 08:05:25 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id IAA03062 for ; Thu, 30 Jul 1998 08:04:16 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma003053; Thu, 30 Jul 98 08:04:13 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id IAA04770 for ; Thu, 30 Jul 1998 08:03:38 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma004643; Thu, 30 Jul 98 08:03:24 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id IAA05850; Thu, 30 Jul 1998 08:03:31 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA04513 for ; Thu, 30 Jul 1998 06:03:29 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id IAA10122 for ; Thu, 30 Jul 1998 08:03:27 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma010106; Thu, 30 Jul 98 08:03:11 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id IAA22551 for ; Thu, 30 Jul 1998 08:33:28 -0400 (EDT) Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id IAA06245 for ; Thu, 30 Jul 1998 08:33:27 -0400 (EDT) Received: from tootsie.cisco.com (tootsie.cisco.com [171.69.128.44]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with SMTP id FAA00894 for ; Thu, 30 Jul 1998 05:33:25 -0700 (PDT) Message-Id: <3.0.5.32.19980730082725.007e17d0@zipper.cisco.com> X-Sender: bstewart@zipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 30 Jul 1998 08:27:25 -0400 To: disman@nexen.com From: Bob Stewart Subject: Re: Context in Notification Logging MIB In-Reply-To: <199807300732.JAA12765@henkell.ibr.cs.tu-bs.de> References: <3.0.5.32.19980729171941.00843390@zipper.cisco.com> <3.0.5.32.19980729171941.00843390@zipper.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 09:32 AM 7/30/98 +0200, Juergen Schoenwaelder wrote: >However, I am a bit confused about the intention expressed in section >3 in says: > >> This MIB provides infrastructure for other MIBs in the form of a >> local logging function. It is intended strictly for senders of >> notifications. > >This being part of the "distributed management" WG, I would like to >see this MIB written so that you can also use it to log notifications >received from other devices in addition to notifications originated at >the local SNMP engine. Having contextEngineId and contextName columns >in the nlmLogTable makes this possible. The intention was to meet a minimum need and not to worry about what it would take to log notifications incoming from elsewhere. Since the brave new world of SNMPv3 recognizes that local is in some sense elsewhere, what with multiple engines and contexts, logging alien notifications comes along free as far as the MIB is concerned. So my attempt at simplified goals is futile and I'll remove it. Bob From maria@xedia.com Thu Jul 30 15:47: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 PAA04067 for ; Thu, 30 Jul 1998 15:47:24 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA00698 for ; Thu, 30 Jul 1998 15:46:15 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma000696; Thu, 30 Jul 98 15:46:10 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id PAA11575 for ; Thu, 30 Jul 1998 15:45:35 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma011307; Thu, 30 Jul 98 15:45:14 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id PAA23620; Thu, 30 Jul 1998 15:45:48 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA06911 for ; Thu, 30 Jul 1998 13:45:46 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA00688 for ; Thu, 30 Jul 1998 15:45:45 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma000677; Thu, 30 Jul 98 15:45:33 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id QAA04571 for ; Thu, 30 Jul 1998 16:16:38 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id QAA10962 for ; Thu, 30 Jul 1998 16:16:33 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA28666 for ; Thu, 30 Jul 1998 15:16:32 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma028631; Thu, 30 Jul 98 15:16:14 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id PAA12151 for ; Thu, 30 Jul 1998 15:15:39 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma011586; Thu, 30 Jul 98 15:15:11 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id PAA14614 for ; Thu, 30 Jul 1998 15:15:44 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA06687 for disman@nexen.com; Thu, 30 Jul 1998 13:15:44 -0700 (PDT) Date: Thu, 30 Jul 1998 13:15:44 -0700 (PDT) From: Randy Presuhn Message-Id: <199807302015.NAA06687@dorothy.bmc.com> To: disman@nexen.com Subject: Re: WG Last Call: Script MIB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - The WG last call for ends July 31, 1998. Does anyone committed to reviewing and commenting on this document need additional time? I'd also like to hear from those who HAVE read the document and not found the need to comment. ----------------------------------------------------------------------- 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 maria@xedia.com Thu Jul 30 15:48: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 PAA04082 for ; Thu, 30 Jul 1998 15:48:26 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA00742 for ; Thu, 30 Jul 1998 15:47:17 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma000738; Thu, 30 Jul 98 15:47:11 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id PAA12605 for ; Thu, 30 Jul 1998 15:46:36 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma012500; Thu, 30 Jul 98 15:46:29 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id PAA23848; Thu, 30 Jul 1998 15:47:02 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA06992 for ; Thu, 30 Jul 1998 13:47:01 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id PAA10531 for ; Thu, 30 Jul 1998 15:46:59 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma010469; Thu, 30 Jul 98 15:46:24 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id QAA04638 for ; Thu, 30 Jul 1998 16:20:23 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id QAA10987 for ; Thu, 30 Jul 1998 16:20:17 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA29233 for ; Thu, 30 Jul 1998 15:20:15 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma029108; Thu, 30 Jul 98 15:19:40 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id PAA15913 for ; Thu, 30 Jul 1998 15:19:05 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma015389; Thu, 30 Jul 98 15:18:39 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id PAA15509 for ; Thu, 30 Jul 1998 15:19:12 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA06711 for disman@nexen.com; Thu, 30 Jul 1998 13:19:12 -0700 (PDT) Date: Thu, 30 Jul 1998 13:19:12 -0700 (PDT) From: Randy Presuhn Message-Id: <199807302019.NAA06711@dorothy.bmc.com> To: disman@nexen.com Subject: Re: WG Last Call: schedule MIB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - The WG last call for ends July 31, 1998. Does anyone committed to reviewing and commenting on this document need additional time? If you HAVE read the document and not found any problems with it, I'd like to hear from you, too. So far I've seen one proposed change (an editorial correction) proposed and accepted on this mailing list. This change would be incorporated in the I-D submitted to the IESG for approval. ----------------------------------------------------------------------- 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 maria@xedia.com Thu Jul 30 16:21: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 QAA04332 for ; Thu, 30 Jul 1998 16:21:21 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA02665 for ; Thu, 30 Jul 1998 16:20:12 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma002655; Thu, 30 Jul 98 16:19:51 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA10632 for ; Thu, 30 Jul 1998 16:19:16 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma010143; Thu, 30 Jul 98 16:18:39 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA03920; Thu, 30 Jul 1998 16:18:45 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA07145 for ; Thu, 30 Jul 1998 14:18:43 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA02615 for ; Thu, 30 Jul 1998 16:18:41 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma002604; Thu, 30 Jul 98 16:18:19 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id QAA05599 for ; Thu, 30 Jul 1998 16:51:59 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id QAA08625 for ; Thu, 30 Jul 1998 16:51:44 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA01083 for ; Thu, 30 Jul 1998 15:51:39 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma001067; Thu, 30 Jul 98 15:51:22 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id PAA16845 for ; Thu, 30 Jul 1998 15:50:47 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma016726; Thu, 30 Jul 98 15:50:41 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id PAA25239 for ; Thu, 30 Jul 1998 15:51:15 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA07034 for disman@nexen.com; Thu, 30 Jul 1998 13:51:14 -0700 (PDT) Date: Thu, 30 Jul 1998 13:51:14 -0700 (PDT) From: Randy Presuhn Message-Id: <199807302051.NAA07034@dorothy.bmc.com> To: disman@nexen.com Subject: Proposed disman agenda Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi dismaniacs - I'd appreciate having a volunteer for the role of minute-taker BEFORE the meeting; please read http://www.ietf.org/instructions/minutes.html if you're interested. If you'd like to give a presentation, please contact me so I can allocate time and include you in the agenda. Do take the time to read http://www.ietf.org/instructions/slides.html Here's a proposal for an agenda for our meeting in Chicago: 1. Adminstrative matters 1.1 selection of minute-taker 1.2 circulation of signup sheet 1.3 Review of Agenda 1.4 Allocation of time 2. Status of Current work 2.1 Script MIB 2.2 Schedule MIB 2.3 Notification/Log MIB 2.4 Event MIB 2.5 Expression MIB 2.6 Framework 3. Review of Interactions with other working groups 3.1 SNMPv3 issues (forwarded from SNMPv3 WG meeting on Monday) 3.2 AgentX issues (forwarded from AgentX WG meeting on Wednesday) 4. Charter updates 4.1 completed items 4.2 changes to target dates 4.3 Possibile additions to charter: 4.3.1 Remote Operations MIB http://ftp.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-00.txt (an update may soon be available) 4.3.2 "Script MIB Extensibility" http://www.ibr.cs.tu-bs.de/projects/jasmin/smx.ps 5. Technical Presentations 5.1 implementation reports 6. Wrap-up 6.1 reminders to minute-takers and presenters 6.2 retrieval of sign-up sheet Comments appreciated. ----------------------------------------------------------------------- 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 maria@xedia.com Thu Jul 30 16:57: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 QAA04611 for ; Thu, 30 Jul 1998 16:57:50 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA04571 for ; Thu, 30 Jul 1998 16:56:40 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma004555; Thu, 30 Jul 98 16:56:22 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA10287 for ; Thu, 30 Jul 1998 16:55:46 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma009978; Thu, 30 Jul 98 16:55:20 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA14677; Thu, 30 Jul 1998 16:55:50 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA07493 for ; Thu, 30 Jul 1998 14:55:48 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id QAA15070 for ; Thu, 30 Jul 1998 16:55:46 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma015056; Thu, 30 Jul 98 16:55:37 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id RAA06139 for ; Thu, 30 Jul 1998 17:23:43 -0400 (EDT) Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id RAA08748 for ; Thu, 30 Jul 1998 17:23:41 -0400 (EDT) Received: from tootsie.cisco.com (tootsie.cisco.com [171.69.128.44]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with SMTP id OAA04598 for ; Thu, 30 Jul 1998 14:23:35 -0700 (PDT) Message-Id: <3.0.5.32.19980730172332.007c5790@zipper.cisco.com> X-Sender: bstewart@zipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 30 Jul 1998 17:23:32 -0400 To: Distributed Management WG From: Bob Stewart Subject: Interim Draft - Notification Log MIB Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Here is a new draft of the Notification Log MIB on its way to becoming draft-ietf-disman-notif-log-mib-03.txt. I'm sending it here first for a sanity check but I don't have much time. The Internet Draft deadline for the August IETF meeting is Friday, 7 August, and I still have to finish the Event and Expression MIBs. If I get quick comments I'll incorporate what I can. This draft has the following changes from the previous draft: Updated boilerplate. Added a real overview, including security operation. Especially note what I did with security for lack of a better idea. I made the security depend on the *contents* of MIB objects in related tables. Although this is computable it sure won't fall out for free in any implementation I can imagine. This is your chance to suggest improvements. Corrected the SYNTAX of nlmNotificationID and various other typos. Separated some of the objects in the variable table so it now directly reflects the wire-visible SNMP data types. Changed the capacity configuration for units of entries or bytes and stated operation when reducing the limit. Allowed limit to be hard coded. Added a logged variable count for each notification and made the variable index monotonic from one. Clarified that only one variable value per variable is instantiated. Added objects to record the engine ID and context of a notification. Bob --------------- Internet Draft Notification Log MIB 29 July 1998 Notification Log MIB 30 July 1998 draft-ietf-disman-notif-log-mib-03.txt Bob Stewart Cisco Systems, Inc. bstewart@cisco.com 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 ``work in progress.'' To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Please send comments to the Distributed Management Working Group, . Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Expires 30 July 1998+6 months [Page 1] Internet Draft Notification Log MIB 29 July 1998 1. 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 managed objects used for logging SNMP Notifications. 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2271 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in RFC 1155 [2], RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC 1904 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2273 [14] and the view-based access control mechanism described in RFC 2275 [15]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate Expires 30 July 1998+6 months [Page 2] Internet Draft Notification Log MIB 29 July 1998 translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. Expires 30 July 1998+6 months [Page 3] Internet Draft Notification Log MIB 29 July 1998 3. Overview Systems that support SNMP often need a mechanism for recording Notification information as a hedge against lost Notifications, whether those are Traps or Informs that exceed retransmission limits. This MIB therefore provides common infrastructure for other MIBs in the form of a local logging function. It is intended primarily for senders of Notifications but could be used also by receivers. Given the Notification Log MIB, individual MIBs bear less responsibility to record the transient information associated with an event against the possibility that the Notification message is lost, and applications can poll the log to know that they have not missed important Notifications or to suspect that they might have. 3.1. Environment The overall environmental concerns for the MIB are: o SNMP Engines and Contexts o Security 3.1.1. SNMP Engines and Contexts As described in the SNMPv3 architecture [1], a given system may support multiple SNMP engines operating independently of one another, each with its own SNMP engine identification. Furthermore, within the perview of a given engine there may be multiple named management contexts supporting overlapping or disjoint sets of MIB objects and Notifications. Thus understanding a particular Notification requires knowing the SNMP engine and management context from whence it came. The simplest system may have only one SNMP engine, and the simplest engine may support only one context. In these cases, knowledge of the engine ID and context name can be assumed and need not be explicit. In a given implementation, an instance of the Notification Log MIB may be confined to a single engine or context or may combine information from multiple engines or contexts, allowing for the full range of exclusive or inclusive contents. To provide the necessary source information for a logged Notification, Expires 30 July 1998+6 months [Page 4] Internet Draft Notification Log MIB 29 July 1998 the MIB includes objects to record that Notification's source SNMP engine ID and management context name. In the case where such information can be assumed, the related object need not be instantiated, thus allowing the simplest implemenetation for the simplest system. 3.1.2. Security Except for the log itself security of this MIB falls under normal SNMP security policies. For the log, Notifications containing objects not within a requester's authorized view will appear not to exist, thus causing apparent holes in the log index space. If the log contains Notifications from SNMP engines not part of the local system, those Notifications fall under the overall local access policy for the log. 3.2. Structure The MIB has the following sections: o Configuration -- control over how much the log can hold and what Notifications are to be logged. o Statistics -- indications of logging activity. o Log -- the Notifications themselves. 3.2.1. Configuration The configuration section contains objects to manage resource use by the MIB in units of either bytes or entries. This section also contains a table that augments the snmpNotifyTable from the standard SNMP Notification MIB, providing a means of deciding which Notifications are to be logged. Expires 30 July 1998+6 months [Page 5] Internet Draft Notification Log MIB 29 July 1998 3.2.2. Statistics The statistics section contains counters for Notifications logged and discarded, supplying a means to understand the results of log capacity configuration. 3.2.3. Log The log contains the Notifications and the objects that came in their variable binding list, indexed by an integer that reflects when the entry was made. An application that wants to collect all logged Notifications or to know if it may have missed any can keep track of the highest index it has retrieved and start from there on its next poll, checking sysUpTime for a discontinuity that would have reset the index and perhaps have lost entries. Variables are in a table indexed by Notification index and variable index within that Notification. The values are kept as a "discriminated union," with one value object per variable. Exactly which value object is instantiated depends on the SNMP data type of the variable, with a separate object of appropriate type for each distinct SNMP data type. An application can thus reconstruct the information from the Notification PDU from what is recorded in the log. Expires 30 July 1998+6 months [Page 6] Internet Draft Notification Log MIB 29 July 1998 4. Definitions NOTIFICATION-LOG-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, experimental, Integer32, Unsigned32, TimeTicks, Counter32, Counter64, IpAddress FROM SNMPv2-SMI TimeStamp, TruthValue FROM SNMPv2-TC SnmpAdminString, SnmpEngineID FROM SNMP-FRAMEWORK-MIB snmpNotifyTable FROM SNMP-NOTIFICATION-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; notificationLogMIB MODULE-IDENTITY LAST-UPDATED "9807301700Z" ORGANIZATION "IETF Distributed Management Working Group" CONTACT-INFO "Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive, San Jose CA 95134-1706. Phone: +1 408 526 4527 Email: bstewart@cisco.com" DESCRIPTION "The MIB module for logging SNMP Notifications, that is, Traps and Informs." ::= { experimental xx } notificationLogMIBObjects OBJECT IDENTIFIER ::= { notificationLogMIB 1 } nlmConfig OBJECT IDENTIFIER ::= { notificationLogMIBObjects 1 } nlmStats OBJECT IDENTIFIER ::= { notificationLogMIBObjects 2 } nlmLog OBJECT IDENTIFIER ::= { notificationLogMIBObjects 3 } -- -- Configuration Section -- nlmConfigEntryLimitUnits OBJECT-TYPE SYNTAX INTEGER { entries(1), bytes(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The units for nlmConfigEntryLimit. See nlmConfigEntryLimit for Expires 30 July 1998+6 months [Page 7] Internet Draft Notification Log MIB 29 July 1998 further details. Implementations may allow choice of unit types or may chose either unit type and not allow it to be changed." ::= { nlmConfig 1 } nlmConfigEntryLimit OBJECT-TYPE SYNTAX Integer32 {-1..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of entries or bytes that can be held in nlmLogTable. A value of -1 indicates no limit. If an application changes the limit while there are Notifications in the log, the oldest Notifications are discarded to bring the log down to the new limit. Measuring in bytes is not necessarily subject to exact external calculations as to what will fit, as the implementation may or may not include internal overhead and is free to use any internal incoding. Implementations may choose a limit and not allow it to be changed." ::= { nlmConfig 2 } -- -- Notify Table Logging Control Column -- nlmConfigNotifyTable OBJECT-TYPE SYNTAX SEQUENCE OF nlmConfigNotifyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A column of logging control entries." ::= { nlmConfig 1 } nlmConfigNotifyEntry OBJECT-TYPE SYNTAX NlmConfigNotifyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A logging control entry." Expires 30 July 1998+6 months [Page 8] Internet Draft Notification Log MIB 29 July 1998 AUGMENTS { snmpNotifyTable } ::= { nlmConfigNotifyTable 1 } NlmConfigNotifyEntry ::= SEQUENCE { nlmConfigNotifyLog TruthValue } nlmConfigNotifyLog OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Control for whether this Notification is logged in nlmLogTable." DEFVAL { false } ::= { nlmConfigNotifyEntry 1 } -- -- Statisitics Section -- nlmStatsNotificationsLogged OBJECT-TYPE SYNTAX Counter32 UNITS "entries" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Notifications put in the nlmLogTable." ::= { nlmStats 1 } nlmStatsEntriesDiscarded OBJECT-TYPE SYNTAX Counter32 UNITS "entries" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of log entries discarded to make room for a new entry or because of a change in nlmConfigEntryLimitUnits or nlmConfigEntryLimit." ::= { nlmStats 2 } -- -- Log Section -- Expires 30 July 1998+6 months [Page 9] Internet Draft Notification Log MIB 29 July 1998 -- -- Log Table -- nlmLogTable OBJECT-TYPE SYNTAX SEQUENCE OF nlmLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Notification log entries. It is an implementation-specific matter whether entries in this table are preserved across initializations of the management system. In general one would expect that they are not." ::= { nlmLog 1 } nlmLogEntry OBJECT-TYPE SYNTAX NlmLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A Notification log entry. Entries appear in this table when Notifications occur and are enabled for logging by nlmConfigNotifyLog. They are removed to make way for new entries or in responsse to an application setting nlmConfigEntryLimit or nlmConfigEntryLimitUnits to reduce capacity." INDEX { nlmLogIndex } ::= { nlmLogTable 1 } NlmLogEntry ::= SEQUENCE { nlmLogIndex Unsigned32, nlmLogTime TimeStamp, nlmLogEngineID SnmpEngineID, nlmLogContextName SnmpAdminString, nlmLogVariables Unsigned32, nlmLogNotificationID OBJECT IDENTIFIER } nlmLogIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION Expires 30 July 1998+6 months [Page 10] Internet Draft Notification Log MIB 29 July 1998 "A monotonically increasing integer for the sole purpose of indexing entries. When it reaches the maximum value, an extremely unlikely event, the agent wraps the value back to 1 and may flush existing entries." ::= { nlmLogEntry 1 } nlmLogTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the entry occurred." ::= { nlmLogEntry 2 } nlmLogEngineID OBJECT-TYPE SYNTAX SnmpEngineID MAX-ACCESS read-only STATUS current DESCRIPTION "The identification of the SNMP engine at which the Notification originated. If the log can contain Notifications from only one engine this object need not be instantiated." ::= { nlmLogEntry 3 } nlmLogContextName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the SNMP MIB context from which the Notification came. If the Notification's source SNMP engine does not support multiple contexts, this object need not be instantiated." ::= { nlmLogEntry 4 } nlmLogVariables OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of variables in nlmLogVariableTable for this Notification." Expires 30 July 1998+6 months [Page 11] Internet Draft Notification Log MIB 29 July 1998 ::= { nlmLogEntry 5 } nlmLogNotificationID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The NOTIFICATION-TYPE object identifer of the Notification that occurred." ::= { nlmLogEntry 6 } -- -- Log Variable Table -- nlmLogVariableTable OBJECT-TYPE SYNTAX SEQUENCE OF nlmLogVariableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of variables to go with Notification log entries." ::= { nlmLog 2 } nlmLogVariableEntry OBJECT-TYPE SYNTAX NlmLogVariableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A Notification log entry variable. Entries appear in this table when there are variables in the varbind list of a Notification in nlmLogTable." INDEX { nlmLogIndex, nlmLogVariableIndex } ::= { nlmLogVariableTable 1 } NlmLogVariableEntry ::= SEQUENCE { nlmLogVariableIndex Unsigned32, nlmLogVariableID OBJECT IDENTIFIER, nlmLogVariableType INTEGER, nlmLogVariableCounter32Val Counter32, nlmLogVariableUnsigned32Val Unsigned32, nlmLogVariableTimeTicksVal TimeTicks, nlmLogVariableInteger32Val Integer32, nlmLogVariableOctetStringVal OCTET STRING, nlmLogVariableIpAddressVal IpAddress, Expires 30 July 1998+6 months [Page 12] Internet Draft Notification Log MIB 29 July 1998 nlmLogVariableOidVal OBJECT IDENTIFIER, nlmLogVariableCounter64Val Counter64 } nlmLogVariableIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A monotonically increasing integer, starting at 1 for a given nlmLogIndex, for indexing variables within the logged Notification. ::= { nlmLogVariableEntry 1 } nlmLogVariableID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The variable's object identifier." ::= { nlmLogVariableEntry 2 } nlmLogVariableValueType OBJECT-TYPE SYNTAX INTEGER { counter32(1), unsignedOrGauge32(2), timeTicks(3), integer32(4), ipAddress(5), octetString(6), objectId(7), counter64(8) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the value. One and only one of the value objects that follow is instantiated, based on this type." ::= { nlmLogVariableEntry 3 } nlmLogVariableCounter32Val OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'counter32'." ::= { nlmLogVariableEntry 4 } nlmLogVariableUnsigned32Val OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION Expires 30 July 1998+6 months [Page 13] Internet Draft Notification Log MIB 29 July 1998 "The value when nlmLogVariableType is 'unsignedOrGauge32'." ::= { nlmLogVariableEntry 5 } nlmLogVariableTimeTicksVal OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'timeTicks'." ::= { nlmLogVariableEntry 6 } nlmLogVariableInteger32Val OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'integer32'." ::= { nlmLogVariableEntry 7 } nlmLogVariableOctetStringVal OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'octetString'." ::= { nlmLogVariableEntry 8 } nlmLogVariableIpAddressVal OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'ipAddress'. ::= { nlmLogVariableEntry 9 } nlmLogVariableOidVal OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'objectId'." ::= { nlmLogVariableEntry 10 } nlmLogVariableCounter64Val OBJECT-TYPE SYNTAX Counter64 Expires 30 July 1998+6 months [Page 14] Internet Draft Notification Log MIB 29 July 1998 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'counter64'." ::= { nlmLogVariableEntry 11 } -- -- Conformance -- notificationLogMIBConformance OBJECT IDENTIFIER ::= { notificationLogMIB 3 } notificationLogMIBCompliances OBJECT IDENTIFIER ::= { notificationLogMIBConformance 1 } notificationLogMIBGroups OBJECT IDENTIFIER ::= { notificationLogMIBConformance 2 } -- Compliance notificationLogMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities which implement the Notification Log MIB." MODULE -- this module MANDATORY-GROUPS { notificationLogConfigGroup, notificationLogStatsGroup, notificationLogLogGroup } ::= { notificationLogMIBCompliances 1 } -- Units of Conformance notificationLogConfigGroup OBJECT-GROUP OBJECTS { nlmConfigEntryLimitUnits, nlmConfigEntryLimit, nlmConfigNotifyLog } STATUS current DESCRIPTION "Notification log configuration management." ::= { notificationLogMIBGroups 1 } notificationLogStatsGroup OBJECT-GROUP OBJECTS { Expires 30 July 1998+6 months [Page 15] Internet Draft Notification Log MIB 29 July 1998 nlmStatsNotificationsLogged, nlmStatsEntriesDiscarded } STATUS current DESCRIPTION "Notification log statistics." ::= { notificationLogMIBGroups 2 } notificationLogLogGroup OBJECT-GROUP OBJECTS { nlmLogTime, nlmLogEngineID, nlmLogContextName, nlmLogVariables, nlmLogNotificationID, nlmLogVariableID, nlmLogVariableType, nlmLogVariableCounter32Val, nlmLogVariableUnsigned32Val, nlmLogVariableTimeTicks32Val, nlmLogVariableInteger32Val, nlmLogVariableOctetStringVal, nlmLogVariableIpAddressVal, nlmLogVariableOidVal, nlmLogVariableCounter64Val } STATUS current DESCRIPTION "Notification log data." ::= { notificationLogMIBGroups 3 } END Expires 30 July 1998+6 months [Page 16] Internet Draft Notification Log MIB 29 July 1998 5. References [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998 [2] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990 [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991 [4] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, Performance Systems International, March 1991 [5] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [6] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [7] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [8] 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. [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. Expires 30 July 1998+6 months [Page 17] Internet Draft Notification Log MIB 29 July 1998 [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, SNMP Research, Inc., Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998. [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, IBM T. J. Watson Research, January 1998. [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2273, SNMP Research, Inc., Secure Computing Corporation, Cisco Systems, January 1998 [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, Inc., Cisco Systems, Inc., January 1998 Expires 30 July 1998+6 months [Page 18] Internet Draft Notification Log MIB 29 July 1998 6. Security Considerations Security issues are discussed in the overview. 7. Author's Address Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 Phone: 408-526-4527 Email: bstewart@cisco.com Expires 30 July 1998+6 months [Page 19] Internet Draft Notification Log MIB 29 July 1998 Table of Contents 1 Abstract ........................................................ 2 2 The SNMP Management Framework ................................... 2 3 Overview ........................................................ 4 3.1 Environment ................................................... 4 3.1.1 SNMP Engines and Contexts ................................... 4 3.1.2 Security .................................................... 5 3.2 Structure ..................................................... 5 3.2.1 Configuration ............................................... 5 3.2.2 Statistics .................................................. 6 3.2.3 Log ......................................................... 6 4 Definitions ..................................................... 7 5 References ...................................................... 17 6 Security Considerations ......................................... 19 7 Author's Address ................................................ 19 Expires 30 July 1998+6 months [Page 20] From maria@xedia.com Thu Jul 30 18:06: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 SAA05144 for ; Thu, 30 Jul 1998 18:06:52 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id SAA08721 for ; Thu, 30 Jul 1998 18:05:42 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma008701; Thu, 30 Jul 98 18:05:19 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id SAA28844 for ; Thu, 30 Jul 1998 18:04:44 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma028717; Thu, 30 Jul 98 18:04:27 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id SAA03352; Thu, 30 Jul 1998 18:05:00 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id QAA08576 for ; Thu, 30 Jul 1998 16:04:42 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id SAA08665 for ; Thu, 30 Jul 1998 18:04:41 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma008652; Thu, 30 Jul 98 18:04:21 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id SAA07043 for ; Thu, 30 Jul 1998 18:40:57 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id SAA12097 for ; Thu, 30 Jul 1998 18:40:55 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA07377 for ; Thu, 30 Jul 1998 17:40:50 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma007366; Thu, 30 Jul 98 17:40:37 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA14886 for ; Thu, 30 Jul 1998 17:40:00 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma014874; Thu, 30 Jul 98 17:40:00 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id RAA26848; Thu, 30 Jul 1998 17:40:33 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA08213; Thu, 30 Jul 1998 15:40:15 -0700 (PDT) Date: Thu, 30 Jul 1998 15:40:15 -0700 (PDT) From: Randy Presuhn Message-Id: <199807302240.PAA08213@dorothy.bmc.com> To: djw@ironbridgenetworks.com Subject: Re: WG Last Call: schedule MIB Cc: disman@nexen.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - Good catch. I'm forwarding this to the disman list so the whole WG is aware of the issue. Item (2) is an example of a set of general problems that arise with schedules based on civil time (subject to leap seconds, daylight savings time, etc) rather than other time scales that don't have holes or duplicates in them. RFC 1305 and ISO 10164-20 ITU Rec. X.743 going into these issues. ----------------------------------------------------------------------- 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 djw@ironbridgenetworks.com Thu Jul 30 15:19:56 PDT 1998 |Date: Thu, 30 Jul 1998 18:18:33 -0400 |From: David Waitzman |Organization: IronBridgeNetworks |To: Randy Presuhn , levi@snmp.com, | schoenw@ibr.cs.tu-bs.de |Subject: Re: WG Last Call: schedule MIB |References: <199807302019.NAA06711@dorothy.bmc.com> | |Some comments: | |1. Object schedDay is base-0 but still defines d31, which is the 32nd day of |the month. This is also used in the example in section 5.3. This could be |used to indicate the last day of the month, even as the number of days varies |per month, but I assume that that was not what was meant. | |2. Please specify (or say it is implementation dependent) what happens when |daylight saving time transitions occur, ex., what clocks move backward. does |an action scheduled for 1:05 run twice, once for each 1:05 that night? When |clocks move forward, is the action scheduled at 1:05 skipped that night? | |-- |-david waitzman work: djw@ibnets.com play: djw@vineyard.net |IronBridge Networks / 55 Hayden Avenue Voice: 781 402 8061 |Lexington MA 02421 Fax: 781 402 8092 | | | From maria@xedia.com Fri Jul 31 09:42: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 JAA12259 for ; Fri, 31 Jul 1998 09:42:01 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id JAA14444 for ; Fri, 31 Jul 1998 09:40:52 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma014430; Fri, 31 Jul 98 09:40:38 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id JAA00859 for ; Fri, 31 Jul 1998 09:40:03 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma029964; Fri, 31 Jul 98 09:39:30 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id JAA02903; Fri, 31 Jul 1998 09:40:01 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA11508 for ; Fri, 31 Jul 1998 07:39:47 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id JAA26466 for ; Fri, 31 Jul 1998 09:38:59 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma026437; Fri, 31 Jul 98 09:38:49 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id KAA16681 for ; Fri, 31 Jul 1998 10:11:03 -0400 (EDT) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id KAA14790 for ; Fri, 31 Jul 1998 10:10:58 -0400 (EDT) Received: from alden ([10.128.1.25]) by dokka.maxware.no (8.8.5/8.8.5) with SMTP id QAA09408; Fri, 31 Jul 1998 16:06:45 +0200 Message-Id: <3.0.2.32.19980731154317.013255d0@dokka.maxware.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Fri, 31 Jul 1998 15:43:17 +0200 To: Randy Presuhn , djw@ironbridgenetworks.com From: Harald Tveit Alvestrand Subject: Re: WG Last Call: schedule MIB Cc: disman@nexen.com In-Reply-To: <199807302240.PAA08213@dorothy.bmc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" (triggered by David Waitzmann's note) |2. Please specify (or say it is implementation dependent) what happens when |daylight saving time transitions occur, ex., what clocks move backward. does |an action scheduled for 1:05 run twice, once for each 1:05 that night? When |clocks move forward, is the action scheduled at 1:05 skipped that night? Worse: I could not find in the schedule-mib-04 draft *anything* about whether times specified are in UTC or in local time. Specifying it either way is OK with me; leaving it unspecified is a no-go. Harald A Harald Tveit Alvestrand IETF Area Director, Operations and Management From maria@xedia.com Fri Jul 31 10:24: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 KAA12585 for ; Fri, 31 Jul 1998 10:24:31 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA17022 for ; Fri, 31 Jul 1998 10:23:20 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma017009; Fri, 31 Jul 98 10:22:57 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id KAA14245 for ; Fri, 31 Jul 1998 10:22:21 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma014042; Fri, 31 Jul 98 10:22:08 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id KAA17116; Fri, 31 Jul 1998 10:22:22 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA11588 for ; Fri, 31 Jul 1998 08:22:20 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA16963 for ; Fri, 31 Jul 1998 10:22:19 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma016942; Fri, 31 Jul 98 10:21:54 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id LAA17901 for ; Fri, 31 Jul 1998 11:00:18 -0400 (EDT) Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id LAA16588 for ; Fri, 31 Jul 1998 11:00:17 -0400 (EDT) Received: from nsmdserv.cnd.hp.com (daemon@nsmdserv.cnd.hp.com [15.2.104.118]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id IAA03618 for ; Fri, 31 Jul 1998 08:00:16 -0700 (PDT) Received: from cnd.hp.com (darren.cnd.hp.com) by nsmdserv.cnd.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA054207204; Fri, 31 Jul 1998 09:00:04 -0600 Message-Id: <35C1DBFD.94604070@cnd.hp.com> Date: Fri, 31 Jul 1998 09:00:13 -0600 From: "Darren D. Smith" Organization: OVSD, HP X-Mailer: Mozilla 4.04 [en] (WinNT; I) Mime-Version: 1.0 To: disman@nexen.com Subject: Re: WG Last Call: schedule MIB References: <199807210059.RAA06992@dorothy.bmc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Randy Presuhn wrote: = > Juergen and David have posted > to this mailing list, and it should soon appear in the usual FTP > repositories. As disman chair, I am issuing a Working Group Last Call on > this document, with a deadline for comments of July 31, 1998. My apologies for getting to this late, and for possible asking a question that may have been asked before already. In schedAdminStatus, it contains options for periodic and calendar. Why not a "one-time" value. It would use the same format as the calendar entries, but the entry would be deleted after being run once. This seems like it could be really useful for accomplishing certain types of operations, e.g. reseting an interface at a scheduled time so that everybody knows its going to happen. This is not the type of thing that gets scheduled repeatedly, but is usually scheduled for "this coming Thursday at 10:00". Since this is really an enhancement and not an issue with whats there, its probably not appropriate to delay the MIB from moving forward, so maybe this can be stored as a future idea. -- Darren D. Smith darren_smith@hp.com OVSD, HP -- From maria@xedia.com Fri Jul 31 11:07: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 LAA12912 for ; Fri, 31 Jul 1998 11:07:23 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA21388 for ; Fri, 31 Jul 1998 11:06:13 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma021379; Fri, 31 Jul 98 11:06:07 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA01929 for ; Fri, 31 Jul 1998 11:05:32 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma001666; Fri, 31 Jul 98 11:05:15 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id LAA01576; Fri, 31 Jul 1998 11:05:47 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA11844 for ; Fri, 31 Jul 1998 09:05:44 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id LAA02373 for ; Fri, 31 Jul 1998 11:05:42 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma002339; Fri, 31 Jul 98 11:05:13 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id LAA18764 for ; Fri, 31 Jul 1998 11:38:30 -0400 (EDT) Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id LAA16996 for ; Fri, 31 Jul 1998 11:38:29 -0400 (EDT) Received: from tootsie.cisco.com (tootsie.cisco.com [171.69.128.44]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with SMTP id IAA29545 for ; Fri, 31 Jul 1998 08:38:27 -0700 (PDT) Message-Id: <3.0.5.32.19980731113809.007f4d50@zipper.cisco.com> X-Sender: bstewart@zipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 31 Jul 1998 11:38:09 -0400 To: disman@nexen.com From: Bob Stewart Subject: Re: context in the event and logging MIB In-Reply-To: <199805251014.MAA25884@henkell.ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 12:14 PM 5/25/98 +0200, Juergen Schoenwaelder wrote: >The event MIB has a table which allows to perform a set operation on a >set of targets. It uses the value of mteEventSetObject and >mteEventSetValue to build the varbindlist of the SNMP set-request. I >think there should be at least an mteEventSetContextName object which >identifies the context for the set-operation. You may be right. Why would I need one for the Set object and not for the Get* object in the trigger table (that is, the object being tested to trigger the event)? It seems the Get* object is where I particularly need it. If I have a context for the Get* object could I not say that the context for the Set object is the same as for the particular Get* instance that triggered the event. If I have a context it seems I need to wildcard it, too. I'd wildcard it at the end, same as I do for OIDs. Bob From maria@xedia.com Fri Jul 31 11:24:44 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 LAA13053 for ; Fri, 31 Jul 1998 11:24:43 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA22757 for ; Fri, 31 Jul 1998 11:23:33 -0500 (CDT) Received: from dresden.bmc.com(198.64.253.250) by almond.bmc.com via smap (V2.0) id xma022735; Fri, 31 Jul 98 11:23:13 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA20507 for ; Fri, 31 Jul 1998 11:22:37 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma020359; Fri, 31 Jul 98 11:22:26 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id LAA06703; Fri, 31 Jul 1998 11:22:59 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA12095 for ; Fri, 31 Jul 1998 09:22:57 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA22685 for ; Fri, 31 Jul 1998 11:22:54 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma022660; Fri, 31 Jul 98 11:22:26 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id MAA19482 for ; Fri, 31 Jul 1998 12:04:40 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id MAA17154 for ; Fri, 31 Jul 1998 12:04:38 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA21296 for ; Fri, 31 Jul 1998 11:04:36 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma021279; Fri, 31 Jul 98 11:04:06 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA29589 for ; Fri, 31 Jul 1998 11:03:31 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma029186; Fri, 31 Jul 98 11:03:11 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id LAA00910 for ; Fri, 31 Jul 1998 11:03:44 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA11797 for disman@nexen.com; Fri, 31 Jul 1998 09:03:44 -0700 (PDT) Date: Fri, 31 Jul 1998 09:03:44 -0700 (PDT) From: Randy Presuhn Message-Id: <199807311603.JAA11797@dorothy.bmc.com> To: disman@nexen.com Subject: Re: WG Last Call: schedule MIB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - I'm forwarding this (and a couple of other messages) for the information of the disman WG. ----------------------------------------------------------------------- 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 Fri Jul 31 07:37:14 PDT 1998 |Date: Fri, 31 Jul 1998 16:36:17 +0200 |From: Juergen Schoenwaelder |To: levi@snmp.com |CC: djw@ironbridgenetworks.com, rpresuhn@dorothy.bmc.com |Subject: Re: WG Last Call: schedule MIB |References: <199807311420.KAA21334@hpux10.snmp.com> | | |>>>>> David Levi writes: | |David> These are both good points. How about we make d0(0) for |David> schedDay just be unused/ignored, and also make bit 0 for |David> schedMonth be unused. This way the bit values actually match |David> the day and month. That seems more intuitive to me. | |I would propose to define it like this: | | SYNTAX BITS { | d1(0), d2(1), d3(2), d4(3), d5(4) | d6(5), d7(6), d8(7), d9(8), d10(9), | d11(10), d12(11), d13(12), d14(13), d15(14), | d16(15), d17(16), d18(17), d19(18), d20(19), | d21(20), d22(21), d23(22), d24(23), d25(24), | d26(25), d27(26), d28(27), d29(28), d30(29), | d31(30) | } | |The labels counts from 1 (because that is intuitive) while the bit |position in the OCTET STRING counts from 0. Do you think this is too |confusing? I mean, someone who encodes the OCTET STRING value by hand |will probably intuitively set the first bit (0) if he wants to |schedule something on the first day in a months. | |David> I think we should follow the rules that cron uses in dealing |David> with daylight savings. | |Are there any common rules? The vixie cron implementation wakes up |every minutes and starts whatever matches the current time. So I guess |it will either start a job twice or no job at all during transition |from/to daylight savings time. Similarily, I guess it will also start |jobs multiple times if you move the clock backwards (e.g. during |coarse grained clock synchronization.) | |Giving a general answer to this type of problem is not trivial. I |propose to add text which discusses this problem but does not require |a specific behaviour. | Juergen | | From maria@xedia.com Fri Jul 31 11:25:59 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 LAA13065 for ; Fri, 31 Jul 1998 11:25:58 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA22893 for ; Fri, 31 Jul 1998 11:24:47 -0500 (CDT) Received: from dresden.bmc.com(198.64.253.250) by almond.bmc.com via smap (V2.0) id xma022860; Fri, 31 Jul 98 11:24:15 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA21709 for ; Fri, 31 Jul 1998 11:23:40 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma021079; Fri, 31 Jul 98 11:23:09 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id LAA06944; Fri, 31 Jul 1998 11:23:43 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA12140 for ; Fri, 31 Jul 1998 09:23:41 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id LAA03465 for ; Fri, 31 Jul 1998 11:23:40 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma003457; Fri, 31 Jul 98 11:23:22 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id MAA19485 for ; Fri, 31 Jul 1998 12:05:19 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id MAA17158 for ; Fri, 31 Jul 1998 12:05:10 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA21321 for ; Fri, 31 Jul 1998 11:05:07 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma021300; Fri, 31 Jul 98 11:04:36 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA00248 for ; Fri, 31 Jul 1998 11:04:01 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma000208; Fri, 31 Jul 98 11:03:59 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id LAA01150 for ; Fri, 31 Jul 1998 11:04:33 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA11805 for disman@nexen.com; Fri, 31 Jul 1998 09:04:32 -0700 (PDT) Date: Fri, 31 Jul 1998 09:04:32 -0700 (PDT) From: Randy Presuhn Message-Id: <199807311604.JAA11805@dorothy.bmc.com> To: disman@nexen.com Subject: Re: WG Last Call: schedule MIB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - I'm forwarding this (and a couple of other messages) for the information of the disman WG. ----------------------------------------------------------------------- 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 levi@snmp.com Fri Jul 31 07:50:18 PDT 1998 |To: Juergen Schoenwaelder |cc: djw@ironbridgenetworks.com, rpresuhn@dorothy.bmc.com, levi@snmp.com |Subject: Re: WG Last Call: schedule MIB |Date: Fri, 31 Jul 1998 10:49:47 -0400 |From: David Levi | |> |> >>>>> David Levi writes: |> |> David> These are both good points. How about we make d0(0) for |> David> schedDay just be unused/ignored, and also make bit 0 for |> David> schedMonth be unused. This way the bit values actually match |> David> the day and month. That seems more intuitive to me. |> |> I would propose to define it like this: |> |> SYNTAX BITS { |> d1(0), d2(1), d3(2), d4(3), d5(4) |> d6(5), d7(6), d8(7), d9(8), d10(9), |> d11(10), d12(11), d13(12), d14(13), d15(14), |> d16(15), d17(16), d18(17), d19(18), d20(19), |> d21(20), d22(21), d23(22), d24(23), d25(24), |> d26(25), d27(26), d28(27), d29(28), d30(29), |> d31(30) |> } |> |> The labels counts from 1 (because that is intuitive) while the bit |> position in the OCTET STRING counts from 0. Do you think this is too |> confusing? I mean, someone who encodes the OCTET STRING value by hand |> will probably intuitively set the first bit (0) if he wants to |> schedule something on the first day in a months. | |This looks fine. | |> |> David> I think we should follow the rules that cron uses in dealing |> David> with daylight savings. |> |> Are there any common rules? The vixie cron implementation wakes up |> every minutes and starts whatever matches the current time. So I guess |> it will either start a job twice or no job at all during transition |> from/to daylight savings time. Similarily, I guess it will also start |> jobs multiple times if you move the clock backwards (e.g. during |> coarse grained clock synchronization.) | |The man page for cron on an hpux10.01 system has a good discussion |of its behaviour. I guess this is just how HP decided to do it, |but I think it makes sense. | |> |> Giving a general answer to this type of problem is not trivial. I |> propose to add text which discusses this problem but does not require |> a specific behaviour. | |I think we ought to specify what the behaviour should be. You should |get the same results when you configure the MIB on two different |systems the exact same way. | |It's really not that complicated, here's the text from the HP man page: | | Spring and Autumn Time Transitions | On the days of daylight savings (summer) time transition (in time | zones and countries where daylight savings time applies), cron | schedules commands differently from normal. | | In the following description, an ambiguous time refers to an hour and | minute that occurs twice in the same day because of a daylight savings | time transition (usually on a day during the Autumn season). A | nonexistent time refers to an hour and minute that does not occur | because of a daylight savings time transition (usually on a day during | the Spring season). DST-shift refers to the offset that is applied to | standard time to result in daylight savings time. This is normally | one hour, but can be any combination of hours and minutes up to 23 | hours and 59 minutes (see tztab(4)). | | When a command is specified to run at an ambiguous time, the command | is executed only once at the first occurrence of the ambiguous time. | | When a command is specified to run at a nonexistent time, the command | is executed after the specified time by an amount of time equal to the | DST-shift. When such an adjustment would conflict with another time | specified to run the command, the command is run only once rather than | running the command twice at the same time. | | Commands that are scheduled to run during all hours (there is a * is | in the hour field of the crontab entry) are scheduled without any | adjustment. | |I don't know if there are any copyright restrictions on this. |We can ask HP about that. | |-Dave | From maria@xedia.com Fri Jul 31 11:32:32 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 LAA13117 for ; Fri, 31 Jul 1998 11:32:31 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA23625 for ; Fri, 31 Jul 1998 11:31:21 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma023620; Fri, 31 Jul 98 11:31:19 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA29149 for ; Fri, 31 Jul 1998 11:30:44 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma028768; Fri, 31 Jul 98 11:30:20 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id LAA09253; Fri, 31 Jul 1998 11:30:53 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA12303 for ; Fri, 31 Jul 1998 09:30:52 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA23602 for ; Fri, 31 Jul 1998 11:30:50 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma023511; Fri, 31 Jul 98 11:30:20 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA28133 for ; Fri, 31 Jul 1998 11:29:45 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by dresden.bmc.com via smap (3.2) id xma027659; Fri, 31 Jul 98 11:29:20 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id MAA19466 for ; Fri, 31 Jul 1998 12:03:09 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id MAA17142 for ; Fri, 31 Jul 1998 12:03:08 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA21229 for ; Fri, 31 Jul 1998 11:03:06 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma021185; Fri, 31 Jul 98 11:02:36 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA27949 for ; Fri, 31 Jul 1998 11:02:00 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma027380; Fri, 31 Jul 98 11:01:33 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id LAA00433 for ; Fri, 31 Jul 1998 11:02:07 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA11786 for disman@nexen.com; Fri, 31 Jul 1998 09:02:06 -0700 (PDT) Date: Fri, 31 Jul 1998 09:02:06 -0700 (PDT) From: Randy Presuhn Message-Id: <199807311602.JAA11786@dorothy.bmc.com> To: disman@nexen.com Subject: Re: WG Last Call: schedule MIB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - I'm forwarding this (and a couple of other messages) for the information of the disman WG. ----------------------------------------------------------------------- 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 levi@snmp.com Fri Jul 31 07:20:20 PDT 1998 |To: David Waitzman |cc: Randy Presuhn , schoenw@ibr.cs.tu-bs.de, | levi@snmp.com |Subject: Re: WG Last Call: schedule MIB |Date: Fri, 31 Jul 1998 10:20:26 -0400 |From: David Levi | |> Some comments: |> |> 1. Object schedDay is base-0 but still defines d31, which is the 32nd day of |> the month. This is also used in the example in section 5.3. This could be |> used to indicate the last day of the month, even as the number of days varies |> per month, but I assume that that was not what was meant. |> |> 2. Please specify (or say it is implementation dependent) what happens when |> daylight saving time transitions occur, ex., what clocks move backward. does |> an action scheduled for 1:05 run twice, once for each 1:05 that night? When |> clocks move forward, is the action scheduled at 1:05 skipped that night? | |These are both good points. How about we make d0(0) for schedDay just |be unused/ignored, and also make bit 0 for schedMonth be unused. This |way the bit values actually match the day and month. That seems more |intuitive to me. | |I think we should follow the rules that cron uses in dealing with |daylight savings. | |-Dave | From maria@xedia.com Fri Jul 31 14:53: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 OAA14683 for ; Fri, 31 Jul 1998 14:53:42 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA11699 for ; Fri, 31 Jul 1998 14:52:30 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma011601; Fri, 31 Jul 98 14:51:44 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA12502 for ; Fri, 31 Jul 1998 14:51:08 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma012377; Fri, 31 Jul 98 14:51:01 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id OAA09498; Fri, 31 Jul 1998 14:51:34 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA13609 for ; Fri, 31 Jul 1998 12:51:32 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id OAA16405 for ; Fri, 31 Jul 1998 14:51:30 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma016393; Fri, 31 Jul 98 14:51:20 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id PAA24457 for ; Fri, 31 Jul 1998 15:22:18 -0400 (EDT) Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id PAA18623 for ; Fri, 31 Jul 1998 15:22:16 -0400 (EDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.1/8.9.0) with ESMTP id VAA16868; Fri, 31 Jul 1998 21:22:15 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id VAA01346; Fri, 31 Jul 1998 21:22:14 +0200 Date: Fri, 31 Jul 1998 21:22:14 +0200 Message-Id: <199807311922.VAA01346@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Harald.Alvestrand@maxware.no CC: disman@nexen.com In-reply-to: <3.0.2.32.19980731154317.013255d0@dokka.maxware.no> (message from Harald Tveit Alvestrand on Fri, 31 Jul 1998 15:43:17 +0200) Subject: Re: WG Last Call: schedule MIB References: <3.0.2.32.19980731154317.013255d0@dokka.maxware.no> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII >>>>> Harald Tveit Alvestrand writes: Harald> Worse: I could not find in the schedule-mib-04 draft Harald> *anything* about whether times specified are in UTC or in Harald> local time. They are meant to be in local time. I agree that this needs to be defined somewhere. Juergen Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3289) From maria@xedia.com Fri Jul 31 14:59: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 OAA14728 for ; Fri, 31 Jul 1998 14:59:19 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA11942 for ; Fri, 31 Jul 1998 14:58:06 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma011929; Fri, 31 Jul 98 14:57:44 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA17947 for ; Fri, 31 Jul 1998 14:57:08 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma017892; Fri, 31 Jul 98 14:57:05 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id OAA11390; Fri, 31 Jul 1998 14:57:39 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA13688 for ; Fri, 31 Jul 1998 12:57:37 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA11920 for ; Fri, 31 Jul 1998 14:57:36 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma011911; Fri, 31 Jul 98 14:57:16 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA17414 for ; Fri, 31 Jul 1998 14:56:40 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by dresden.bmc.com via smap (3.2) id xma017001; Fri, 31 Jul 98 14:56:14 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id PAA24656 for ; Fri, 31 Jul 1998 15:28:44 -0400 (EDT) Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id PAA18652 for ; Fri, 31 Jul 1998 15:28:43 -0400 (EDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.1/8.9.0) with ESMTP id VAA17018; Fri, 31 Jul 1998 21:28:40 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id VAA01414; Fri, 31 Jul 1998 21:28:36 +0200 Date: Fri, 31 Jul 1998 21:28:36 +0200 Message-Id: <199807311928.VAA01414@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: dds@cnd.hp.com CC: disman@nexen.com In-reply-to: <35C1DBFD.94604070@cnd.hp.com> (dds@cnd.hp.com) Subject: Re: WG Last Call: schedule MIB References: <199807210059.RAA06992@dorothy.bmc.com> <35C1DBFD.94604070@cnd.hp.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII >>>>> Darren D Smith writes: Darren> In schedAdminStatus, it contains options for periodic and Darren> calendar. Why not a "one-time" value. It would use the same Darren> format as the calendar entries, but the entry would be deleted Darren> after being run once. This seems like it could be really Darren> useful for accomplishing certain types of operations, Darren> e.g. reseting an interface at a scheduled time so that Darren> everybody knows its going to happen. This is not the type of Darren> thing that gets scheduled repeatedly, but is usually scheduled Darren> for "this coming Thursday at 10:00". This certainly makes sense to me. I have not thought about it before and I can't remember that someone brought it up before. Darren> Since this is really an enhancement and not an issue with Darren> whats there, its probably not appropriate to delay the MIB Darren> from moving forward, so maybe this can be stored as a future Darren> idea. I think this depends on a) Randy's view of the procedural aspect and b) the WG's view whether we want to add this feature. The changes seem to be pretty small. Please let us know what you think. Juergen Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3289) From maria@xedia.com Fri Jul 31 15:03: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 PAA14772 for ; Fri, 31 Jul 1998 15:03:36 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA12434 for ; Fri, 31 Jul 1998 15:02:24 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma012334; Fri, 31 Jul 98 15:02:06 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id PAA22261 for ; Fri, 31 Jul 1998 15:01:30 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma021687; Fri, 31 Jul 98 15:00:55 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id PAA12622; Fri, 31 Jul 1998 15:01:27 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA13704 for ; Fri, 31 Jul 1998 13:01:25 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA12201 for ; Fri, 31 Jul 1998 15:01:24 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma012151; Fri, 31 Jul 98 15:00:53 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id PAA20977 for ; Fri, 31 Jul 1998 15:00:13 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by dresden.bmc.com via smap (3.2) id xma020550; Fri, 31 Jul 98 14:59:56 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id PAA25010 for ; Fri, 31 Jul 1998 15:42:25 -0400 (EDT) Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id PAA18347 for ; Fri, 31 Jul 1998 15:42:24 -0400 (EDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.1/8.9.0) with ESMTP id VAA17236; Fri, 31 Jul 1998 21:42:16 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id VAA01523; Fri, 31 Jul 1998 21:42:15 +0200 Date: Fri, 31 Jul 1998 21:42:15 +0200 Message-Id: <199807311942.VAA01523@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: rpresuhn@dorothy.bmc.com CC: disman@nexen.com In-reply-to: <199807311635.JAA12347@dorothy.bmc.com> (message from Randy Presuhn on Fri, 31 Jul 1998 09:35:35 -0700 (PDT)) Subject: Re: WG Last Call: schedule MIB References: <199807311635.JAA12347@dorothy.bmc.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII >>>>> Randy Presuhn writes: Randy> Several issues have been raised with respect to the schedule Randy> MIB during this working group last call, and it is clear that Randy> another draft addressing these issues is needed. I suggest Randy> that the working group resolve these issues by the middle of Randy> next week so that our industrious editors will have a fighting Randy> chance of getting an updated draft out before the I-D cutoff Randy> date. Randy> At that time, I would like to have a minimal (one week, closing Randy> August 14, 1998) WG last call to ensure that everyone is happy Randy> with how the editors have addressed these issues, and then, if Randy> nothing horrible surfaces, forward it to the IESG for approval. This is fine with me. Here is my list of issues that came up so far together with a proposed solution. #1 'monday' and 'friday' must be exchanged in the example in section 5.3. #2 Need to specify that dates and times are always within in the local time zone. #3 Need to change the enumeration of schedDay as follows: SYNTAX BITS { d1(0), d2(1), d3(2), d4(3), d5(4) d6(5), d7(6), d8(7), d9(8), d10(9), d11(10), d12(11), d13(12), d14(13), d15(14), d16(15), d17(16), d18(17), d19(18), d20(19), d21(20), d22(21), d23(22), d24(23), d25(24), d26(25), d27(26), d28(27), d29(28), d30(29), d31(30) } #4 Need to add text similar to the one in the cron documentation which solves the ambiguity of calendar schedules during transition to or from daylight savings time. (Other ambiguities caused by clocks that are jumping back or forward are implementation specific.) We also have one request for a new feature: #5 Addition of a one-shot calendar scheduling mode. I would like to hear ASAP is someone objects to the proposed solution to #1-#4. And I certainly would like to know your feelings with regard to #5. Juergen Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3289) From maria@xedia.com Fri Jul 31 15:14:04 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 PAA14858 for ; Fri, 31 Jul 1998 15:14:03 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA13403 for ; Fri, 31 Jul 1998 15:12:51 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xmaa13377; Fri, 31 Jul 98 15:12:30 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id PAA01875 for ; Fri, 31 Jul 1998 15:11:53 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma001816; Fri, 31 Jul 98 15:11:50 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id PAA16032; Fri, 31 Jul 1998 15:12:22 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA13769 for ; Fri, 31 Jul 1998 13:12:19 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA13341 for ; Fri, 31 Jul 1998 15:12:17 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma013298; Fri, 31 Jul 98 15:11:56 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id PAA01411 for ; Fri, 31 Jul 1998 15:11:21 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by dresden.bmc.com via smap (3.2) id xma001115; Fri, 31 Jul 98 15:11:02 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id PAA25185 for ; Fri, 31 Jul 1998 15:53:18 -0400 (EDT) Received: from relay2.smtp.psi.net (relay2.smtp.psi.net [38.8.188.2]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id PAA18866 for ; Fri, 31 Jul 1998 15:53:17 -0400 (EDT) Received: from [192.152.208.5] (helo=acecomm.com) by relay2.smtp.psi.net with smtp (Exim 1.90 #1) id 0z2LEh-0007je-00; Fri, 31 Jul 1998 15:53:13 -0400 Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA15390; Fri, 31 Jul 1998 15:55:18 -0400 Message-Id: <9807311955.AA15390@acecomm.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Fri, 31 Jul 1998 15:55:27 -0400 To: Juergen Schoenwaelder From: Bob Natale Subject: Re: WG Last Call: schedule MIB Cc: rpresuhn@dorothy.bmc.com, disman@nexen.com In-Reply-To: <199807311942.VAA01523@henkell.ibr.cs.tu-bs.de> References: <199807311635.JAA12347@dorothy.bmc.com> <199807311635.JAA12347@dorothy.bmc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 7/31/98 09:42 PM, Juergen Schoenwaelder wrote: Hi Juergen, <...> >We also have one request for a new feature: > >#5 Addition of a one-shot calendar scheduling mode. <...> >And I certainly would like to know your feelings with >regard to #5. I think it's a necessary case that must be accommodated. Since it is really just a logical extension of existing related cases, I don't think this addition should delay the progress of the MIB. 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 ------------- Free downloads at www.winsnmp.com ------------- From maria@xedia.com Fri Jul 31 16:26:37 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 QAA15433 for ; Fri, 31 Jul 1998 16:26:36 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA20320 for ; Fri, 31 Jul 1998 16:25:24 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma020241; Fri, 31 Jul 98 16:25:11 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA08344 for ; Fri, 31 Jul 1998 16:24:35 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma006384; Fri, 31 Jul 98 16:22:18 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA05115; Fri, 31 Jul 1998 16:22:52 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA14929 for ; Fri, 31 Jul 1998 14:22:33 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA20133 for ; Fri, 31 Jul 1998 16:22:18 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma020123; Fri, 31 Jul 98 16:21:54 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id MAA19986 for ; Fri, 31 Jul 1998 12:36:12 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id MAA15613 for ; Fri, 31 Jul 1998 12:36:11 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA23871 for ; Fri, 31 Jul 1998 11:36:05 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma023856; Fri, 31 Jul 98 11:35:54 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA03696 for ; Fri, 31 Jul 1998 11:35:19 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma003433; Fri, 31 Jul 98 11:35:03 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id LAA10635 for ; Fri, 31 Jul 1998 11:35:36 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA12347 for disman@nexen.com; Fri, 31 Jul 1998 09:35:35 -0700 (PDT) Date: Fri, 31 Jul 1998 09:35:35 -0700 (PDT) From: Randy Presuhn Message-Id: <199807311635.JAA12347@dorothy.bmc.com> To: disman@nexen.com Subject: Re: WG Last Call: schedule MIB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - Today was scheduled to be the closed of the disman WG last call for the schedule MIB. Several issues have been raised with respect to the schedule MIB during this working group last call, and it is clear that another draft addressing these issues is needed. I suggest that the working group resolve these issues by the middle of next week so that our industrious editors will have a fighting chance of getting an updated draft out before the I-D cutoff date. At that time, I would like to have a minimal (one week, closing August 14, 1998) WG last call to ensure that everyone is happy with how the editors have addressed these issues, and then, if nothing horrible surfaces, forward it to the IESG for approval. Any objections? ----------------------------------------------------------------------- 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." -----------------------------------------------------------------------