Subject: ResourceType & ResourceId

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Dec 2001 23:21:54 +0100

Can someone explain the rationale for using (ResourceType/ResourceId)
pairs to identify alarm sources? The enumeration currently only
identifies interfaces, physical entities and applications and the
ResourceId requires that the target table is indexed by a single
integer. Would a RowPointer not be a more general and not necessarily
more complicated choice?

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Muehlenpfordtstr. 23, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <http://www.ibr.cs.tu-bs.de/~schoenw/>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 14 Dec 2001 00:32:46 +0200

I think that this is nothing more than human readability. One RowPointer
object would work as well, but it would make somehow more difficult for
a human or an application to answer to the question 'what are the alarms
related to interfaces?'.

Regards,

Dan

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 20 Dec 2001 11:14:41 -0800 (PST)

Hi -

I'm forwarding a posting from Reva Bailey.
I've added her address to the disman "posters" list
so future postings from this address won't be delayed.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 [email-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------

> Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117])
> 	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA18161
> 	for <[email-masked]>; Thu, 20 Dec 2001 10:42:37 -0800 (PST)
> From: [email-masked]
> Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1])
> 	by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id fBKIfWE08030
> 	for <[email-masked]>; Thu, 20 Dec 2001 12:41:32 -0600 (CST)
> Received: from sj1-3-4-7.securesites.net (sj1-3-4-7.securesites.net [192.220.127.200])
> 	by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 683671FF027
> 	for <[email-masked]>; Thu, 20 Dec 2001 18:35:07 -0600 (CST)
> Received: (qmail 93322 invoked by uid 16517); 20 Dec 2001 18:43:35 -0000
> Message-ID: <[email-masked]>
> Subject: Re: ResourceType & ResourceId
> To: [email-masked]
> Date: Thu, 20 Dec 2001 18:43:35 +0000 (GMT)
> In-Reply-To: <[email-masked]> from "Juergen Schoenwaelder" at Dec 18, 2001 06:04:32 PM
> X-Mailer: ELM [version 2.5 PL6]
> MIME-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> 
> My preference is RowPointer.  I have not yet supported the
> Entity Mib.  The hardware objects in my chassis mib that can be
> in an alarm state are multi-column indexed tables.
> 
> Reva Bailey
> 
> TiMetra, Inc.  
> [email-masked] i
> 650-237-5123 
> 
> > 
> > >>>>> Sharon Chisholm writes:
> > 
> > [...]
> > 
> > We obviously both fail to convince each other of the right solution.
> > So instead of trying one more time to convince you, I just recognize
> > that we to disagree on this issue.
> > 
> > I would be helpful if other folks on this list could share their
> > thoughts with us.
> > 
> > /js
> > 
> > --

---

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 20 Dec 2001 16:07:49 -0500

hi

> in an alarm state are multi-column indexed tables.

Is your example supporting my view or Juergen's ;-)?

In this case you can use can either
	1 Support the entity MIB ;-)
	2 Use the resource type of other 
	3 Identify your resource using the alarm variable table

I added the resource type/ID pair to consistently identify
resources. The original method of the alarm variable table
still works for arbitrary resources.

I say we continue this debate and in the meantime I'll send
in -04 as soon as Dan's done reviewing it. We can then decide
if this issue gates us from going to working group last call.

Sharon

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 27 Dec 2001 11:43:44 -0800 (PST)

Hi -

> Date: Tue, 18 Dec 2001 18:04:32 +0100
> Message-Id: <[email-masked]>
> From: Juergen Schoenwaelder <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> In-reply-to: <[email-masked]>
>       ([email-masked])
> References:  <[email-masked]>
...
> I would be helpful if other folks on this list could share their
...

As a technical contributor, I'm inclined to agree with Juergen
that a RowPointer seems to make more sense.  My reasons:

    1) For the MIBs with which I am most familiar, simple integer
       indexing simply doesn't work.

    2) Having multiple mechanisms to get from the Active Alarm
       to the affected resource sounds like unnecessary
       complication.  I think it's better to have a single
       mechanism, not matter what kind of resource is involved.

    3) If one wanted to craft an access control policy
       to govern who could see alarm information based on
       the resources to which they already have access, a
       RowPointer approach would be much easier to support
       from the perspective of the security administrator
       application configuring VACM.  However, this is a weak
       argument given the rest of the indexing currently in
       the MIB.

Some of my concerns:
        - length of OIDs
        - use case for finding active alarms for a particular
          instance of a resource
        - use case for finding active alarms for all instances
          of a particular kind of resource
        - use case for finding all active alarms
        - number of round trips needed to retrieve an active 
          alarm with all its supporting information

As WG chair, I'd also like to see what others have to say.