Received: from cnri by ietf.org id aa09750; 3 Feb 97 16:31 EST Received: from guelah.nexen.com by CNRI.Reston.VA.US id aa22614; 3 Feb 97 16:31 EST Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id QAA21976; Mon, 3 Feb 1997 16:20:21 -0500 (EST) Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id QAA21325 for disman-out; Mon, 3 Feb 1997 16:06:53 -0500 (EST) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id QAA21315 for ; Mon, 3 Feb 1997 16:06:50 -0500 (EST) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by guelah.nexen.com (8.7.3/8.7.3) with SMTP id QAA21887 for ; Mon, 3 Feb 1997 16:06:48 -0500 (EST) Received: from [171.69.128.42] (gryphon.cisco.com [171.69.128.42]) by puli.cisco.com (8.6.12/8.6.5) with ESMTP id NAA24312 for ; Mon, 3 Feb 1997 13:06:42 -0800 X-Sender: bstewart@puli.cisco.com Message-Id: In-Reply-To: <199701302147.WAA12961@atlas.cs.utwente.nl> References: (message from Bob Stewart on Thu, 30 Jan 1997 16:02:03 -0500) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-pression: awestruck amazement Date: Mon, 3 Feb 1997 16:02:27 -0500 To: disman@nexen.com From: Bob Stewart Subject: Re: (F2) OwnerString definition. Sender: owner-disman@nexen.com Precedence: bulk X-Info: [Un]Subscribe to disman-request@nexen.com, submissions to disman@nexen.com Circa 10:47 PM +0100 1/30/97, Juergen Schoenwaelder bitwhacked: >Bob> The fact that OwnerString was a DisplayString argues against >Bob> that. Display strings are for people to look at. Their use >Bob> for programs to look at is naughty. > >Programs can deal with human readable strings very well to identify >ownership. All the RMON boxes out there prove this statement. I really >do not understand the problem here. Please explain. Programs can't deal with them unless their format is precisely specified or commonly agreed. Owner String is not. >Please explain why you think that the >usage of OCTET STRINGs for smCodeText creates problems. Same as for a DisplayString. The format is not specified and unless it is either specified or somehow agreed, programs can't use it. Making it an OCTET STRING is worse than a DisplayString because you can't even count on being able to display it for a human to look at. Bob   Received: from cnri by ietf.org id aa10963; 3 Feb 97 17:12 EST Received: from guelah.nexen.com by CNRI.Reston.VA.US id aa23944; 3 Feb 97 17:12 EST Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id RAA22418; Mon, 3 Feb 1997 17:04:11 -0500 (EST) Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id RAA22060 for disman-out; Mon, 3 Feb 1997 17:02:58 -0500 (EST) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id RAA22051 for ; Mon, 3 Feb 1997 17:02:56 -0500 (EST) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by guelah.nexen.com (8.7.3/8.7.3) with SMTP id RAA22375 for ; Mon, 3 Feb 1997 17:02:54 -0500 (EST) Received: from myrtilos.cs.utwente.nl by utrhcs.cs.utwente.nl (SMI-8.6/csrelay-SVR4_1.3/RBCS) id XAA28276; Mon, 3 Feb 1997 23:02:42 +0100 Received: from watt.cs.utwente.nl by myrtilos.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id XAA17903; Mon, 3 Feb 1997 23:02:44 +0100 Received: by watt.cs.utwente.nl (SMI-8.6/SMI-SVR4) id XAA12393; Mon, 3 Feb 1997 23:02:44 +0100 Date: Mon, 3 Feb 1997 23:02:44 +0100 Message-Id: <199702032202.XAA12393@watt.cs.utwente.nl> From: Juergen Schoenwaelder To: bstewart@cisco.com CC: disman@nexen.com In-reply-to: (message from Bob Stewart on Mon, 3 Feb 1997 16:02:27 -0500) Subject: Re: (F2) OwnerString definition. Sender: owner-disman@nexen.com Precedence: bulk X-Info: [Un]Subscribe to disman-request@nexen.com, submissions to disman@nexen.com Bob Stewart said: >Please explain why you think that the usage of OCTET STRINGs for >smCodeText creates problems. Bob> Same as for a DisplayString. The format is not specified and Bob> unless it is either specified or somehow agreed, programs Bob> can't use it. Making it an OCTET STRING is worse than a Bob> DisplayString because you can't even count on being able to Bob> display it for a human to look at. The smCodeText instances are related to a scripting language (it is part of the index) and the lanugage runtime system is the entity that has to understand the format. This format is language dependent and you are right if you want to point out that this format should be specified in the object identifier assignement for a language. However, I still don't see a problem with using OCTET STRING values to write a script into the smCodeTable since a) the sending manager selects the language to be used (and hence he can be expected to know the format used by the selected language), b) the receiving manager can easily identify the language (because it is part of the index) and feed the OCTET STRING sequence into the correct runtime system. A similar reasoning can be made for OwnerStrings. It is important to look who is expected to "understand" an OwnerString value. Juergen -- Juergen Schoenwaelder schoenw@cs.utwente.nl http://www.cs.utwente.nl/~schoenw Computer Science Department, University of Twente, (Fax: +31-53-489-3247) P.O. Box 217, NL-7500 AE Enschede, The Netherlands. (Tel. +31-53-489-3678)   Received: from cnri by ietf.org id aa27635; 4 Feb 97 5:07 EST Received: from guelah.nexen.com by CNRI.Reston.VA.US id aa06345; 4 Feb 97 5:07 EST Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id EAA24761; Tue, 4 Feb 1997 04:58:32 -0500 (EST) Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id EAA28753 for disman-out; Tue, 4 Feb 1997 04:56:49 -0500 (EST) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id EAA28744 for ; Tue, 4 Feb 1997 04:56:46 -0500 (EST) Received: from jyra0.jyra.com (jyra0.jyra.com [194.168.77.65]) by guelah.nexen.com (8.7.3/8.7.3) with SMTP id EAA24718 for ; Tue, 4 Feb 1997 04:56:39 -0500 (EST) Received: from JYRA10.jyra.com (192.168.42.174) by jyra0.jyra.com (EMWAC SMTPRS 0.60) with SMTP id ; Tue, 04 Feb 1997 09:56:20 +0000 Received: by JYRA10.jyra.com with Microsoft Mail id <01BC1281.D498DC00@JYRA10.jyra.com>; Tue, 4 Feb 1997 09:57:28 -0000 Message-ID: <01BC1281.D498DC00@JYRA10.jyra.com> From: Pete Lynch To: "'disman@nexen.com'" Subject: smExecAdminStatus, smExecOperStatus and smExecInterval Date: Tue, 4 Feb 1997 09:57:27 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-disman@nexen.com Precedence: bulk X-Info: [Un]Subscribe to disman-request@nexen.com, submissions to disman@nexen.com I interpret the semantics of these to be: smExecAdminStatus = 1 => Try and run the script at the specified interval. Do nothing other than set smExecOperStatus to 1 smExecAdminStatus = 2 => Try and stop the script and dont start it again smExecAdminStatus = 3 => A one shot if the script is not already running. smExecAdminStatus will go back to its previous value after the script execution is initiated. This will be attempted no matter what the value of smExecErrorBehaviour and smExecLastError smExecOperStatus = 3 => The script is in the midst of execution smExecOperStatus = 2 => The script will not run smExecOperStatus = 1 => The script is ready to run at the next smExecInterval unless: - smExecInterval is 0 - smExecRemaining is 0 - smExecErrorBehaviour = 2 and smExecLastError != 0 or it can be kicked by an smExecAdminStatus=3 Comments? (There was no text in the document).   Received: from cnri by ietf.org id aa27656; 4 Feb 97 5:09 EST Received: from guelah.nexen.com by CNRI.Reston.VA.US id aa06370; 4 Feb 97 5:09 EST Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id FAA24815; Tue, 4 Feb 1997 05:00:16 -0500 (EST) Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id EAA28777 for disman-out; Tue, 4 Feb 1997 04:59:16 -0500 (EST) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id EAA28768 for ; Tue, 4 Feb 1997 04:59:14 -0500 (EST) Received: from jyra0.jyra.com (jyra0.jyra.com [194.168.77.65]) by guelah.nexen.com (8.7.3/8.7.3) with SMTP id EAA24771 for ; Tue, 4 Feb 1997 04:59:06 -0500 (EST) Received: from JYRA10.jyra.com (192.168.42.174) by jyra0.jyra.com (EMWAC SMTPRS 0.60) with SMTP id ; Tue, 04 Feb 1997 09:58:47 +0000 Received: by JYRA10.jyra.com with Microsoft Mail id <01BC1282.2C97DE10@JYRA10.jyra.com>; Tue, 4 Feb 1997 09:59:56 -0000 Message-ID: <01BC1282.2C97DE10@JYRA10.jyra.com> From: Pete Lynch To: "'disman@nexen.com'" Subject: RE: (F2) OwnerString definition. Date: Tue, 4 Feb 1997 09:59:54 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-disman@nexen.com Precedence: bulk X-Info: [Un]Subscribe to disman-request@nexen.com, submissions to disman@nexen.com The format is specified - its OCTETs suitable for the language identified in smLanguage ---------- From: Bob Stewart Sent: 03 February 1997 21:02 To: disman@nexen.com Subject: Re: (F2) OwnerString definition. Circa 10:47 PM +0100 1/30/97, Juergen Schoenwaelder bitwhacked: >Bob> The fact that OwnerString was a DisplayString argues against >Bob> that. Display strings are for people to look at. Their use >Bob> for programs to look at is naughty. > >Programs can deal with human readable strings very well to identify >ownership. All the RMON boxes out there prove this statement. I really >do not understand the problem here. Please explain. Programs can't deal with them unless their format is precisely specified or commonly agreed. Owner String is not. >Please explain why you think that the >usage of OCTET STRINGs for smCodeText creates problems. Same as for a DisplayString. The format is not specified and unless it is either specified or somehow agreed, programs can't use it. Making it an OCTET STRING is worse than a DisplayString because you can't even count on being able to display it for a human to look at. Bob   Received: from cnri by ietf.org id aa07228; 4 Feb 97 10:15 EST Received: from guelah.nexen.com by CNRI.Reston.VA.US id aa13233; 4 Feb 97 10:15 EST Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id KAA26657; Tue, 4 Feb 1997 10:04:51 -0500 (EST) Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id KAA01029 for disman-out; Tue, 4 Feb 1997 10:02:48 -0500 (EST) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id KAA01020 for ; Tue, 4 Feb 1997 10:02:45 -0500 (EST) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by nexen.nexen.com (8.7.3/8.7.3) with SMTP id KAA11383 for ; Tue, 4 Feb 1997 10:02:44 -0500 (EST) Received: from myrtilos.cs.utwente.nl by utrhcs.cs.utwente.nl (SMI-8.6/csrelay-SVR4_1.3/RBCS) id QAA05933; Tue, 4 Feb 1997 16:02:15 +0100 Received: from atlas.cs.utwente.nl by myrtilos.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id QAA04968; Tue, 4 Feb 1997 16:02:11 +0100 Received: by atlas.cs.utwente.nl (SMI-8.6/SMI-SVR4) id QAA17155; Tue, 4 Feb 1997 16:02:10 +0100 Date: Tue, 4 Feb 1997 16:02:10 +0100 Message-Id: <199702041502.QAA17155@atlas.cs.utwente.nl> From: Juergen Schoenwaelder To: pete@jyra.com CC: disman@nexen.com In-reply-to: <01BC1281.D498DC00@JYRA10.jyra.com> (message from Pete Lynch on Tue, 4 Feb 1997 09:57:27 -0000) Subject: Re: smExecAdminStatus, smExecOperStatus and smExecInterval Sender: owner-disman@nexen.com Precedence: bulk X-Info: [Un]Subscribe to disman-request@nexen.com, submissions to disman@nexen.com Pete Lynch said: Pete> I interpret the semantics of these to be: [... snip ...] Pete> Comments? (There was no text in the document). Your interpretation is basically correct. However, Dave and I agreed in San Jose that the smExecTable needs to be rewritten because: a) the scheduling service of the DISMAN framework MIB should be used (once it is defined), b) there should be an entry in the smExecTable for every script which starts execution, because otherwise the same instance of smExecLastResult and smExecLastError will be written by multiple scripts. This change also automatically leads to a history of script results. Some controls need to be added to age-out old entries from the smExecTable. We did not make any changes yet because we were more or less waiting for the scheduling part of the DISMAN framework MIB. However, it should be possible to simply remove the scheduling stuff and to go ahead with a definition of the smExecTable which only allows to start scripts by SNMP set operations. We can later integrate the changes to use the DISMAN scheduling service. Juergen -- Juergen Schoenwaelder schoenw@cs.utwente.nl http://www.cs.utwente.nl/~schoenw Computer Science Department, University of Twente, (Fax: +31-53-489-3247) P.O. Box 217, NL-7500 AE Enschede, The Netherlands. (Tel. +31-53-489-3678)   Received: from cnri by ietf.org id aa07649; 4 Feb 97 10:30 EST Received: from guelah.nexen.com by CNRI.Reston.VA.US id aa13648; 4 Feb 97 10:30 EST Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id KAA26843; Tue, 4 Feb 1997 10:21:06 -0500 (EST) Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id KAA01278 for disman-out; Tue, 4 Feb 1997 10:20:08 -0500 (EST) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id KAA01269 for ; Tue, 4 Feb 1997 10:20:05 -0500 (EST) Received: from jyra0.jyra.com (jyra0.jyra.com [194.168.77.65]) by guelah.nexen.com (8.7.3/8.7.3) with SMTP id KAA26794 for ; Tue, 4 Feb 1997 10:19:57 -0500 (EST) Received: from JYRA10.jyra.com (192.168.42.174) by jyra0.jyra.com (EMWAC SMTPRS 0.60) with SMTP id ; Tue, 04 Feb 1997 15:19:41 +0000 Received: by JYRA10.jyra.com with Microsoft Mail id <01BC12AF.0026A280@JYRA10.jyra.com>; Tue, 4 Feb 1997 15:20:49 -0000 Message-ID: <01BC12AF.0026A280@JYRA10.jyra.com> From: Pete Lynch To: "'disman@nexen.com'" Subject: RE: smExecAdminStatus, smExecOperStatus and smExecInterval Date: Tue, 4 Feb 1997 15:20:47 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-disman@nexen.com Precedence: bulk X-Info: [Un]Subscribe to disman-request@nexen.com, submissions to disman@nexen.com I think a better way would be to keep the smExecTable as it is, but to have a separate result table listing the result of each attempt. Our scripts are java threads and do not necessarily reinitialize between executions, but they do generate at least one result row per execution. ---------- From: Juergen Schoenwaelder Sent: 04 February 1997 15:02 To: pete@jyra.com Cc: disman@nexen.com Subject: Re: smExecAdminStatus, smExecOperStatus and smExecInterval Pete Lynch said: Pete> I interpret the semantics of these to be: [... snip ...] Pete> Comments? (There was no text in the document). Your interpretation is basically correct. However, Dave and I agreed in San Jose that the smExecTable needs to be rewritten because: a) the scheduling service of the DISMAN framework MIB should be used (once it is defined), b) there should be an entry in the smExecTable for every script which starts execution, because otherwise the same instance of smExecLastResult and smExecLastError will be written by multiple scripts. This change also automatically leads to a history of script results. Some controls need to be added to age-out old entries from the smExecTable. We did not make any changes yet because we were more or less waiting for the scheduling part of the DISMAN framework MIB. However, it should be possible to simply remove the scheduling stuff and to go ahead with a definition of the smExecTable which only allows to start scripts by SNMP set operations. We can later integrate the changes to use the DISMAN scheduling service. Juergen -- Juergen Schoenwaelder schoenw@cs.utwente.nl http://www.cs.utwente.nl/~schoenw Computer Science Department, University of Twente, (Fax: +31-53-489-3247) P.O. Box 217, NL-7500 AE Enschede, The Netherlands. (Tel. +31-53-489-3678)   Received: from cnri by ietf.org id aa14291; 4 Feb 97 11:46 EST Received: from guelah.nexen.com by CNRI.Reston.VA.US id aa15707; 4 Feb 97 11:46 EST Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id LAA27543; Tue, 4 Feb 1997 11:38:26 -0500 (EST) Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id LAA02354 for disman-out; Tue, 4 Feb 1997 11:32:50 -0500 (EST) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id LAA02345 for ; Tue, 4 Feb 1997 11:32:47 -0500 (EST) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by guelah.nexen.com (8.7.3/8.7.3) with SMTP id LAA27460 for ; Tue, 4 Feb 1997 11:32:45 -0500 (EST) Received: from myrtilos.cs.utwente.nl by utrhcs.cs.utwente.nl (SMI-8.6/csrelay-SVR4_1.3/RBCS) id RAA07123; Tue, 4 Feb 1997 17:32:38 +0100 Received: from atlas.cs.utwente.nl by myrtilos.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id RAA06879; Tue, 4 Feb 1997 17:32:21 +0100 Received: by atlas.cs.utwente.nl (SMI-8.6/SMI-SVR4) id RAA19412; Tue, 4 Feb 1997 17:32:20 +0100 Date: Tue, 4 Feb 1997 17:32:20 +0100 Message-Id: <199702041632.RAA19412@atlas.cs.utwente.nl> From: Juergen Schoenwaelder To: pete@jyra.com CC: disman@nexen.com In-reply-to: <01BC12AF.0026A280@JYRA10.jyra.com> (message from Pete Lynch on Tue, 4 Feb 1997 15:20:47 -0000) Subject: Re: smExecAdminStatus, smExecOperStatus and smExecInterval Sender: owner-disman@nexen.com Precedence: bulk X-Info: [Un]Subscribe to disman-request@nexen.com, submissions to disman@nexen.com Pete Lynch said: Pete> I think a better way would be to keep the smExecTable as it is, Pete> but to have a separate result table listing the result of each Pete> attempt. Pete> Our scripts are java threads and do not necessarily reinitialize Pete> between executions, but they do generate at least one result Pete> row per execution. We need to clarify the terms we use. What is your definition of "attempt"? What do you call an "execution"? I guess that my definition of script execution more or less maps to your definition of "attempt". My point was that the smExecTable should have en entry for each "attempt" (to use your terms) and that the scheduling functions (which you probably call executions) should be aligned with the DISMAN framework scheduling table(s). We probably want the same, but we are using different terms to describe what we want. Is this statement correct? Juergen -- Juergen Schoenwaelder schoenw@cs.utwente.nl http://www.cs.utwente.nl/~schoenw Computer Science Department, University of Twente, (Fax: +31-53-489-3247) P.O. Box 217, NL-7500 AE Enschede, The Netherlands. (Tel. +31-53-489-3678)   Received: from cnri by ietf.org id aa26213; 4 Feb 97 14:29 EST Received: from [204.249.96.19] by CNRI.Reston.VA.US id aa20929; 4 Feb 97 14:29 EST Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id OAA28686; Tue, 4 Feb 1997 14:20:57 -0500 (EST) Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id OAA06822 for disman-out; Tue, 4 Feb 1997 14:18:36 -0500 (EST) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id OAA06813 for ; Tue, 4 Feb 1997 14:18:33 -0500 (EST) Received: from jyra0.jyra.com (jyra0.jyra.com [194.168.77.65]) by guelah.nexen.com (8.7.3/8.7.3) with SMTP id OAA28594 for ; Tue, 4 Feb 1997 14:16:07 -0500 (EST) Received: from JYRA10.jyra.com (192.168.42.174) by jyra0.jyra.com (EMWAC SMTPRS 0.60) with SMTP id ; Tue, 04 Feb 1997 19:15:51 +0000 Received: by JYRA10.jyra.com with Microsoft Mail id <01BC12CF.FEC561D0@JYRA10.jyra.com>; Tue, 4 Feb 1997 19:17:00 -0000 Message-ID: <01BC12CF.FEC561D0@JYRA10.jyra.com> From: Pete Lynch To: 'Juergen Schoenwaelder' Cc: "disman@nexen.com" Subject: RE: smExecAdminStatus, smExecOperStatus and smExecInterval Date: Tue, 4 Feb 1997 19:16:58 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-disman@nexen.com Precedence: bulk X-Info: [Un]Subscribe to disman-request@nexen.com, submissions to disman@nexen.com I guess that my definition of script execution more or less maps to your definition of "attempt". My point was that the smExecTable should have en entry for each "attempt" (to use your terms) and that the scheduling functions (which you probably call executions) should be aligned with the DISMAN framework scheduling table(s). We agree on this point. One entry in a table, probably smExecTable, to document each failed or successful execution attempt. Sorry for my imprecision. I also request one entry in some table to describe an activity which has been initialised with a set of arguments, but which may not be presently running, and which after an execution, will write an entry to smExecTable. In the current MIB, smExecTable fulfils both of these functions, and also fulfils the role of scheduling. This requirement is independent of the need for scheduling, and independent of the smScriptTable. We probably want the same, but we are using different terms to describe what we want. Is this statement correct? Yes, and no, as described above. Juergen Pete   Received: from cnri by ietf.org id aa26941; 4 Feb 97 14:48 EST Received: from guelah.nexen.com by CNRI.Reston.VA.US id aa21454; 4 Feb 97 14:48 EST Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id OAA29003; Tue, 4 Feb 1997 14:41:24 -0500 (EST) Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id OAA07222 for disman-out; Tue, 4 Feb 1997 14:40:20 -0500 (EST) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id OAA07213 for ; Tue, 4 Feb 1997 14:40:18 -0500 (EST) Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by nexen.nexen.com (8.7.3/8.7.3) with SMTP id OAA17165 for ; Tue, 4 Feb 1997 14:40:16 -0500 (EST) Received: from abierman-ss20 (abierman-ss20.cisco.com [171.69.197.254]) by cheerios.cisco.com (8.6.10/8.6.5) with SMTP id LAA29117; Tue, 4 Feb 1997 11:40:05 -0800 Message-ID: <32F7909C.EB4@cisco.com> Date: Tue, 04 Feb 1997 11:40:12 -0800 From: Andy Bierman Organization: Cisco Systems, Inc X-Mailer: Mozilla 3.0C-CISCOEN8 (X11; U; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: Bob Stewart CC: disman@nexen.com Subject: Re: (F2) OwnerString definition. References: (message from Bob Stewart on Thu, 30 Jan 1997 16:02:03 -0500) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@nexen.com Precedence: bulk X-Info: [Un]Subscribe to disman-request@nexen.com, submissions to disman@nexen.com Bob Stewart wrote: > > Circa 10:47 PM +0100 1/30/97, Juergen Schoenwaelder bitwhacked: > >Bob> The fact that OwnerString was a DisplayString argues against > >Bob> that. Display strings are for people to look at. Their use > >Bob> for programs to look at is naughty. > > > >Programs can deal with human readable strings very well to identify > >ownership. All the RMON boxes out there prove this statement. I really > >do not understand the problem here. Please explain. > > Programs can't deal with them unless their format is precisely specified or > commonly agreed. Owner String is not. I disagree. For the resource-sharing algorithm defined in RMON, if the NMS finds an entry for which the OwnerString starts with "monitor", it knows this row can be shared by multiple NMS apps, and that only the monitor should delete this entry. If a suitable monitor-owned entry is not found, then an NMS can look for its own OwnerString values, and re-use those entries. If the NMS app recognizes other NMS apps' OwnerStrings, it's because a resource-sharing model exists between the apps. The OwnerString is 'scratch-pad memory' for any such resource-sharing model. Except for marking its own entries (with 'monitor' prefix), the agent is not involved in the process at all. Perhaps there should be a standard for NMS-apps to share control-table entries on an agent. If so, that WG effort will be responsible for defining the MIB objects required. The RMON, IF-MIB, and DISMAN WGs must leave the OwnerString format 'fuzzy', until a standard exists for row-sharing. Defining an OwnerString format is just one small aspect of that effort. > Bob Andy   Received: from cnri by ietf.org id aa27470; 4 Feb 97 15:02 EST Received: from guelah.nexen.com by CNRI.Reston.VA.US id aa21822; 4 Feb 97 15:02 EST Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id OAA29113; Tue, 4 Feb 1997 14:55:10 -0500 (EST) Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id OAA07450 for disman-out; Tue, 4 Feb 1997 14:54:04 -0500 (EST) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id OAA07441 for ; Tue, 4 Feb 1997 14:54:02 -0500 (EST) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by nexen.nexen.com (8.7.3/8.7.3) with SMTP id OAA17319 for ; Tue, 4 Feb 1997 14:54:00 -0500 (EST) Received: from myrtilos.cs.utwente.nl by utrhcs.cs.utwente.nl (SMI-8.6/csrelay-SVR4_1.3/RBCS) id UAA08467; Tue, 4 Feb 1997 20:53:48 +0100 Received: from watt.cs.utwente.nl by myrtilos.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id UAA09005; Tue, 4 Feb 1997 20:53:47 +0100 Received: by watt.cs.utwente.nl (SMI-8.6/SMI-SVR4) id UAA16674; Tue, 4 Feb 1997 20:53:48 +0100 Date: Tue, 4 Feb 1997 20:53:48 +0100 Message-Id: <199702041953.UAA16674@watt.cs.utwente.nl> From: Juergen Schoenwaelder To: pete@jyra.com CC: disman@nexen.com In-reply-to: <01BC12CF.FEC561D0@JYRA10.jyra.com> (message from Pete Lynch on Tue, 4 Feb 1997 19:16:58 -0000) Subject: Re: smExecAdminStatus, smExecOperStatus and smExecInterval Sender: owner-disman@nexen.com Precedence: bulk X-Info: [Un]Subscribe to disman-request@nexen.com, submissions to disman@nexen.com Pete Lynch said: Pete> I also request one entry in some table to describe an activity Pete> which has been initialised with a set of arguments, but which Pete> may not be presently running, and which after an execution, Pete> will write an entry to smExecTable. I agree that we have to define a mechanism which allows to pass pre-defined parameters to a script. One solution would be to have two similar tables where the first one (lets call it smCloneTable until we find a better name) is used to initialize a row in the smExecTable. This allows to pass parameters (arguments, ownership, etc.) to a script. (One entry in the smCloneTable could be used to initialize multiple script executions (which is identical to multiple rows in the smExecTable).) There are probably other solutions - I have to think a bit more about this issue. Suggestions welcome. ;-) Juergen -- Juergen Schoenwaelder schoenw@cs.utwente.nl http://www.cs.utwente.nl/~schoenw Computer Science Department, University of Twente, (Fax: +31-53-489-3247) P.O. Box 217, NL-7500 AE Enschede, The Netherlands. (Tel. +31-53-489-3678)   Received: from cnri by ietf.org id aa23120; 11 Feb 97 13:44 EST Received: from guelah.nexen.com by CNRI.Reston.VA.US id aa19224; 11 Feb 97 13:44 EST Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id NAA00784; Tue, 11 Feb 1997 13:32:43 -0500 (EST) Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id NAA03263 for disman-out; Tue, 11 Feb 1997 13:11:57 -0500 (EST) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id NAA03254 for ; Tue, 11 Feb 1997 13:11:54 -0500 (EST) Received: from charity.harvard.net (charity.harvard.net [206.137.222.16]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id NAA00615 for ; Tue, 11 Feb 1997 13:11:51 -0500 (EST) Received: from xedia.com (madway.xedia.com [198.202.232.199]) by charity.harvard.net (8.8.5/8.7.3) with SMTP id NAA00665 for ; Tue, 11 Feb 1997 13:10:20 -0500 (EST) Received: from (espanola) by xedia.com (4.1/SMI-4.1) id AA19256; Tue, 11 Feb 97 13:07:22 EST Received: by (5.x/SMI-SVR4) id AA15360; Tue, 11 Feb 1997 13:11:49 -0500 Date: Tue, 11 Feb 1997 13:11:49 -0500 Message-Id: <9702111811.AA15360@> From: Maria Greene To: disman@nexen.com Subject: Changing of the guard! Sender: owner-disman@nexen.com Precedence: bulk X-Info: [Un]Subscribe to disman-request@nexen.com, submissions to disman@nexen.com Hello, all. I'd like to announce that effective now I'm resigning as chair of the Distributed Mangagement working group. Unfortunately, my other projects (including becoming an independent contractor, contracting at an intense start-up, and expecting a baby in May) don't leave me enough time to do the role justice. I'm very happy to annouce that Randy Presuhn of BMC Software (formerly Peer Networks) will be taking over as chair. Randy brings a lot of experience with network management, the IETF, and ITU standards efforts in the distributed management area to the job. Randy will be negotiating a new schedule for the group with Deirdre or the new O&M Area Director soon. You can contact Randy at rpresuhn@bmc.com. I'm happy and encouraged with the recent progress that's been made on disman and I plan to continue contributing as a working group member. Thanks to everyone who has helped us get this far and to Randy for his help in getting us the rest of the way! Maria Greene maria@xedia.com   Received: from cnri by ietf.org id aa10944; 21 Feb 97 11:26 EST Received: from guelah.nexen.com by CNRI.Reston.VA.US id aa15904; 21 Feb 97 11:26 EST Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id LAA14946; Fri, 21 Feb 1997 11:11:07 -0500 (EST) Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id KAA04323 for disman-out; Fri, 21 Feb 1997 10:57:26 -0500 (EST) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id KAA04312 for ; Fri, 21 Feb 1997 10:57:21 -0500 (EST) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by nexen.nexen.com (8.7.3/8.7.3) with SMTP id KAA01808 for ; Fri, 21 Feb 1997 10:57:19 -0500 (EST) Received: from [171.69.128.42] (gryphon.cisco.com [171.69.128.42]) by puli.cisco.com (8.6.12/8.6.5) with ESMTP id HAA28515 for ; Fri, 21 Feb 1997 07:57:16 -0800 X-Sender: bstewart@puli.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Feb 1997 10:57:07 -0500 To: Distributed Management WG From: Bob Stewart Subject: Identification and Indexing Sender: owner-disman@nexen.com Precedence: bulk X-Info: [Un]Subscribe to disman-request@nexen.com, submissions to disman@nexen.com The design team has discussed various topics and in conjunction with our new chair we believe we need to get these discussed on the mailing list. The intent is to get other views and ideas so we can go back and integrate them into our documents. So, with that overall introduction I want to start a discussion. Based on our experience with ifIndexes and ifAlias, I've come to the conclusion that some situations call for two unique identifications, in one-to-one correspondence. I'd like to establish an example of that in the mgmt MIB since that's 1) a good opportunity, and 2) the sort of situation I believe needs this technique. For example, I believe we want these for the list of systems to which a managed system might send unsolicited messages and perhaps other elements (such as expressions) as well, but that will be subject of a separate post. First I want to come to some conclusion on the technique itself. The idea is similar to the long, meaningful names in one-to-one correspondence with short, handy integers used in RMON-2's protocol ID handling. This is crossed with the idea of an ifAlias and its relationship to an ifIndex. The result is a convention for handling certain naming and indexing situations. Some elements need an identification that is under administrative control and is memorable to humans (e.g. ifAlias). A DisplayString nicely satisfies that. It can be assigned by a person or by an application, according to whatever rules they decide. If it avoids having the length tacked in front (use IMPLICIT), it can sort nicely and allow clean partial retrievals of a large table. Note: for the time being let's not argue about DisplayString versus something more international. That's a legitimate but separate topic. When I say DisplayString, think human-readable text with a well-defined lexical order. The problem with a DisplayString is it's long and clumsy for embedding in the middle of an OID and for implementation in general, and it wastes potentially huge amounts of space in messages. This is one reason we so often use our canonical arbitrary small integer. I propose that some elements should have both. Create the element's basic entry with a Set using the DisplayString then do a Get from that table for an integer as a read-only result of the creation. Use the integer everywhere else. Allow the integers to change value between initializations of the management system (e.g. ifIndex), but maintain the association with the DisplayString. Yes, this makes creating an entry a required multi-step process, but in return we get the benefits of both types of identification and indexing. To go with the name-sorted creation table is an integer-indexed mapping table. One of its columns is the name. This column is read-write so that the name can be changed. This makes it possible to administratively rename an element without disturbing anything but the sort order of the creation table. Good applications would present elements by textual name and keep the integers completely hidden. As an example, consider how this would apply to interfaces. When creating an interface, either automatically or by request, it would be assigned a name with the semantics of today's ifAlias. That could be by automated algorithm or random, human choice. All of these names would be in a single table, indexed by name with IMPLICIT length. Unless administratively changed, that name would always mean that interface. That solves the problem of keeping database information related to the right interface. If the names are cleverly chosen, a GetNext sweep of the interface name table could give you an interesting subset. This creation would result, as now, in a read-only ifIndex. The ifIndex would be used in all other tables for indexing and reference. If ifIndexes get shuffled at startup, all such numeric references would automatically be fixed. This assumes that internally a system can do that. Given the implications of ifAlias and the operation of ifIndex today, this is not a big jump. And for the first time it provides an off-system handle, the textual name, that's not subject to random changes, while maintaining the efficiency of integer indexing everywhere else on the managed system. So what do you think? Should we use this approach in appropriate places in the DisMan MIBs? Bob   Received: from cnri by ietf.org id aa29542; 25 Feb 97 7:00 EST Received: from guelah.nexen.com by CNRI.Reston.VA.US id aa08182; 25 Feb 97 7:00 EST Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id GAA29108; Tue, 25 Feb 1997 06:51:03 -0500 (EST) Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id GAA08216 for disman-out; Tue, 25 Feb 1997 06:43:21 -0500 (EST) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id GAA08207 for ; Tue, 25 Feb 1997 06:43:18 -0500 (EST) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by guelah.nexen.com (8.7.3/8.7.3) with SMTP id GAA29059 for ; Tue, 25 Feb 1997 06:43:15 -0500 (EST) Received: from myrtilos.cs.utwente.nl by utrhcs.cs.utwente.nl (SMI-8.6/csrelay-SVR4_1.3/RBCS) id MAA10761; Tue, 25 Feb 1997 12:43:09 +0100 Received: from watt.cs.utwente.nl by myrtilos.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id MAA20504; Tue, 25 Feb 1997 12:43:07 +0100 Received: by watt.cs.utwente.nl (SMI-8.6/SMI-SVR4) id MAA16577; Tue, 25 Feb 1997 12:43:08 +0100 Date: Tue, 25 Feb 1997 12:43:08 +0100 Message-Id: <199702251143.MAA16577@watt.cs.utwente.nl> From: Juergen Schoenwaelder To: bstewart@cisco.com CC: disman@nexen.com In-reply-to: (message from Bob Stewart on Fri, 21 Feb 1997 10:57:07 -0500) Subject: Re: Identification and Indexing Sender: owner-disman@nexen.com Precedence: bulk X-Info: [Un]Subscribe to disman-request@nexen.com, submissions to disman@nexen.com Bob Stewart said: Bob> To go with the name-sorted creation table is an Bob> integer-indexed mapping table. One of its columns is the Bob> name. This column is read-write so that the name can be Bob> changed. This makes it possible to administratively rename an Bob> element without disturbing anything but the sort order of the Bob> creation table. Why do we need the integer-indexed mapping table? Why not put the read-write name column into the table which also defines the integer index? Or do you propose to generalize this idea and to come up with naming/mapping tables that can be used with arbitrary tables (which would be another "service" of the DISMAN framework MIB)? Juergen -- Juergen Schoenwaelder schoenw@cs.utwente.nl http://www.cs.utwente.nl/~schoenw Computer Science Department, University of Twente, (Fax: +31-53-489-3247) P.O. Box 217, NL-7500 AE Enschede, The Netherlands. (Tel. +31-53-489-3678)   Received: from cnri by ietf.org id aa05745; 25 Feb 97 8:55 EST Received: from guelah.nexen.com by CNRI.Reston.VA.US id aa10477; 25 Feb 97 8:55 EST Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id IAA29403; Tue, 25 Feb 1997 08:46:26 -0500 (EST) Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id IAA09042 for disman-out; Tue, 25 Feb 1997 08:45:27 -0500 (EST) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id IAA09033 for ; Tue, 25 Feb 1997 08:45:24 -0500 (EST) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by guelah.nexen.com (8.7.3/8.7.3) with SMTP id IAA29356 for ; Tue, 25 Feb 1997 08:45:22 -0500 (EST) Received: from [171.69.128.42] (gryphon.cisco.com [171.69.128.42]) by puli.cisco.com (8.6.12/8.6.5) with ESMTP id FAA12766 for ; Tue, 25 Feb 1997 05:45:19 -0800 X-Sender: bstewart@puli.cisco.com Message-Id: In-Reply-To: <199702251143.MAA16577@watt.cs.utwente.nl> References: (message from Bob Stewart on Fri, 21 Feb 1997 10:57:07 -0500) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Feb 1997 08:43:39 -0500 To: disman@nexen.com From: Bob Stewart Subject: Re: Identification and Indexing Sender: owner-disman@nexen.com Precedence: bulk X-Info: [Un]Subscribe to disman-request@nexen.com, submissions to disman@nexen.com Circa 6:43 AM -0500 2/25/97, Juergen Schoenwaelder bitwhacked: >Why do we need the integer-indexed mapping table? Why not put the >read-write name column into the table which also defines the integer >index? You need the integer-indexed mapping table so that given a number you can find out the textual name without having to retrieve the whole create/name table. >Or do you propose to generalize this idea and to come up with >naming/mapping tables that can be used with arbitrary tables (which >would be another "service" of the DISMAN framework MIB)? There is no intention for this to be generic in any sense other than as a technique. The textual name/create table and the integer/mapping table would be for a particular element, such as the list of known systems. Something else using the same technique would have its own tables, independent of those. I'm defining a mechanism that solves a limited set of problems in a limited way. It can be reused in different places only in the same sense that we reuse the idea of the arbitrary small integer index. We reapply the technique in different places, independent of one another. Bob   Received: from cnri by ietf.org id aa12157; 25 Feb 97 10:16 EST Received: from guelah.nexen.com by CNRI.Reston.VA.US id aa12318; 25 Feb 97 10:16 EST Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id KAA00185; Tue, 25 Feb 1997 10:06:04 -0500 (EST) Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id KAA10780 for disman-out; Tue, 25 Feb 1997 10:04:32 -0500 (EST) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id KAA10769 for ; Tue, 25 Feb 1997 10:04:28 -0500 (EST) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by nexen.nexen.com (8.7.3/8.7.3) with SMTP id KAA09758 for ; Tue, 25 Feb 1997 10:04:22 -0500 (EST) Received: from myrtilos.cs.utwente.nl by utrhcs.cs.utwente.nl (SMI-8.6/csrelay-SVR4_1.3/RBCS) id QAA13071; Tue, 25 Feb 1997 16:04:10 +0100 Received: from watt.cs.utwente.nl by myrtilos.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id QAA24144; Tue, 25 Feb 1997 16:04:09 +0100 Received: by watt.cs.utwente.nl (SMI-8.6/SMI-SVR4) id QAA17133; Tue, 25 Feb 1997 16:04:09 +0100 Date: Tue, 25 Feb 1997 16:04:09 +0100 Message-Id: <199702251504.QAA17133@watt.cs.utwente.nl> From: Juergen Schoenwaelder To: bstewart@cisco.com CC: disman@nexen.com In-reply-to: (message from Bob Stewart on Tue, 25 Feb 1997 08:43:39 -0500) Subject: Re: Identification and Indexing Sender: owner-disman@nexen.com Precedence: bulk X-Info: [Un]Subscribe to disman-request@nexen.com, submissions to disman@nexen.com Bob Stewart said: Bob> Circa 6:43 AM -0500 2/25/97, Juergen Schoenwaelder bitwhacked: Juergen> Why do we need the integer-indexed mapping table? Why not put the Juergen> read-write name column into the table which also defines the integer Juergen> index? Bob> You need the integer-indexed mapping table so that given a Bob> number you can find out the textual name without having to Bob> retrieve the whole create/name table. This does not answer my question. Why is it not possible to use the table which defines the integer-index for the reverse mapping? An example (the first element is the index in both tables): fooNameTable(name, index) # maps a name to an index fooTable(index, ..., name, rowstatus) # the index defining table # with the name column This allows to retrieve the name with a single get and avoids an addition integer-indexed mapping table. Changing the name is a simple set to the read-write name column of fooTable. Bob> Yes, this makes creating an entry a required multi-step Bob> process, but in return we get the benefits of both types of Bob> identification and indexing. In the example above, row creation could be done in a single step if the manager supplies a valid name and a usable index when setting the RowStatus column to createAndGo or createAndWait. Do you want make creating an entry a two step process so that the agent can create an index value and the manager does not need to bother about choosing an unused index value? Bob> There is no intention for this to be generic in any sense Bob> other than as a technique. The textual name/create table and Bob> the integer/mapping table would be for a particular element, Bob> such as the list of known systems. Something else using the Bob> same technique would have its own tables, independent of Bob> those. Good. Thanks for this clarification. I think that using names to identify rows is very helpful. However, we should be careful to not overload the names in order to group row entries or something similar. Juergen -- Juergen Schoenwaelder schoenw@cs.utwente.nl http://www.cs.utwente.nl/~schoenw Computer Science Department, University of Twente, (Fax: +31-53-489-3247) P.O. Box 217, NL-7500 AE Enschede, The Netherlands. (Tel. +31-53-489-3678)   Received: from cnri by ietf.org id aa21689; 25 Feb 97 13:07 EST Received: from guelah.nexen.com by CNRI.Reston.VA.US id aa16598; 25 Feb 97 13:07 EST Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id MAA01735; Tue, 25 Feb 1997 12:55:49 -0500 (EST) Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id MAA13986 for disman-out; Tue, 25 Feb 1997 12:52:32 -0500 (EST) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id MAA13977 for ; Tue, 25 Feb 1997 12:52:29 -0500 (EST) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by nexen.nexen.com (8.7.3/8.7.3) with SMTP id MAA13374 for ; Tue, 25 Feb 1997 12:52:23 -0500 (EST) Received: from [171.69.128.42] (gryphon.cisco.com [171.69.128.42]) by puli.cisco.com (8.6.12/8.6.5) with ESMTP id JAA22072 for ; Tue, 25 Feb 1997 09:52:19 -0800 X-Sender: bstewart@puli.cisco.com Message-Id: In-Reply-To: <199702251504.QAA17133@watt.cs.utwente.nl> References: (message from Bob Stewart on Tue, 25 Feb 1997 08:43:39 -0500) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Feb 1997 12:52:03 -0500 To: disman@nexen.com From: Bob Stewart Subject: Re: Identification and Indexing Sender: owner-disman@nexen.com Precedence: bulk X-Info: [Un]Subscribe to disman-request@nexen.com, submissions to disman@nexen.com Circa 10:04 AM -0500 2/25/97, Juergen Schoenwaelder bitwhacked: >This does not answer my question. Why is it not possible to use the >table which defines the integer-index for the reverse mapping? An >example (the first element is the index in both tables): > > fooNameTable(name, index) # maps a name to an index > > fooTable(index, ..., name, rowstatus) # the index defining table > # with the name column > >This allows to retrieve the name with a single get and avoids an >addition integer-indexed mapping table. Changing the name is a simple >set to the read-write name column of fooTable. All you did was move the RowStatus to the integer-indexed table, thus breaking the whole thing. The integer index is volatile and assigned by the managed system. You can't use it to create an entry. That's a benefit of the application-selected name for creation. You pick something you can reasonably expect not to be a duplicate and that makes sense to you. The managed system gets to assign the corresponding integer, and reassign it to whatever it wants at every reboot. >In the example above, row creation could be done in a single step if >the manager supplies a valid name and a usable index when setting the >RowStatus column to createAndGo or createAndWait. Do you want make >creating an entry a two step process so that the agent can create an >index value and the manager does not need to bother about choosing an >unused index value? Exactly. We like our little integers and we like having the managed system assign them. If that's not true, why are we standing on our heads to let ifIndexes move around? >I think that using names to identify rows is very helpful. However, >we should be careful to not overload the names in order to group row >entries or something similar. Grouping row entries isn't overloading. It's using. Part of the benefit you get in return for the long names is a meaningful sort order, which you can use as you see fit, as far as it goes. It's a built-in benefit of GetNext. Bob   Received: from cnri by ietf.org id aa29619; 26 Feb 97 0:51 EST Received: from guelah.nexen.com by CNRI.Reston.VA.US id aa02219; 26 Feb 97 0:51 EST Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id AAA04877; Wed, 26 Feb 1997 00:41:45 -0500 (EST) Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id AAA25090 for disman-out; Wed, 26 Feb 1997 00:38:13 -0500 (EST) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id AAA25076 for ; Wed, 26 Feb 1997 00:38:10 -0500 (EST) Received: from palrel3.hp.com ([15.253.88.10]) by nexen.nexen.com (8.7.3/8.7.3) with ESMTP id AAA26977 for ; Wed, 26 Feb 1997 00:36:38 -0500 (EST) Received: from navilu.india.hp.com (shivas@navilu.india.hp.com [15.10.43.40]) by palrel3.hp.com with SMTP (8.7.5/8.7.3) id VAA29353 for ; Tue, 25 Feb 1997 21:35:51 -0800 (PST) Received: by navilu.india.hp.com (1.38.193.4/15.5+ECS 3.3) id AA02928; Wed, 26 Feb 1997 11:09:37 +0500 From: shiva kumar S Message-Id: <9702260609.AA02928@navilu.india.hp.com> Subject: Clarifications on Threshold mib To: disman@nexen.com Date: Wed, 26 Feb 97 11:09:36 IST Cc: sob@harvard.edu, mo@uu.net, kostick@qsun.att.com, bstewart@cisco.com Mailer: Elm [revision: 70.85] Sender: owner-disman@nexen.com Precedence: bulk X-Info: [Un]Subscribe to disman-request@nexen.com, submissions to disman@nexen.com Hi, I am Shivakumar S from Hewlett Packard ISO Bangalore India. I would like to know all developments about Threshold Monitor MIB, I am working on HP openview product and interested in implementing the Threshold Monitor MIB for Network node manager. I visited the IETF work group disman home page and couldn't find any information about Threshold Monitor MIB. I need a copy of Threshold Monitor MIB and also information available on this. We would like to compare that mib with the mib what we have here for NNM and update our mib support. We hope we can have lot of help and support from disman people to complete our Threshold Monitor MIB. -- Thanks & Regards, - SHIVA - <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Shivakumar.S } India Software Operations, { Email: shivas@india.hp.com Hewlett-Packard, } Fax : +91(80)-220 0196 Cunnigham Road, { PH : +91(80)-225 1554, Ext-1237 Bangalore - 560 052, } Email: shivas@india.hp.com India. { >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>