Subject: RE: ResourceType & ResourceId

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 13 Dec 2001 20:15:20 -0500

hi

It's not just a human readability issue, although this would
be more readable using an off the shelf MIB browser. 

It's a usable by manager issue. I'm not a fan of identifying 
things via OID since it means 
	1. The manager needs to track down individual MIBs to be able
	identify what the resource is. Resource Type/Id provides one stop
	shopping

      2. Too much flexibility in identifying the resource leads
	to extra work in the manager that, in my opinion, overshadows
	any benefit you get from OIDs. 

I think there is currently entirely too much freedom in standard
MIBs for identifying resources. I'm not asking for all that data
modelling stuff that got shot down in NIM, but I think we would
benefit from some light weight modelling such as the resource
type/ID pair is suggesting.

If there are known resources that can't be identified using the
suggested method, then we can expand the resource type. Things
that come up in the field can use the alarmVariable table
as either an alternative or to provide clarifying objects.
	
Sharon

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: Thursday, December 13, 2001 5:33 PM
To: Juergen Schoenwaelder; disman
Subject: RE: ResourceType & ResourceId

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
> 
> 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
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 17 Dec 2001 18:54:22 +0100

>>>>> Sharon Chisholm writes:

Sharon> It's a usable by manager issue. I'm not a fan of identifying
Sharon> things via OID since it means

Sharon> 1. The manager needs to track down individual MIBs to be able
Sharon> identify what the resource is. Resource Type/Id provides one
Sharon> stop shopping

Sharon> 2. Too much flexibility in identifying the resource leads to
Sharon> extra work in the manager that, in my opinion, overshadows any
Sharon> benefit you get from OIDs.

The manager does not have to track down individual MIBs - it just
checks for the OIDs it knows about. From a programming point of view,
there is really not much of a difference. Sure, it can help to
document some well known resources so that people use the correct
RowPointer. But restricting the design to well known resource tables
that are indexed by a single integer index has a high potential to
become a problem in the future.

Sharon> If there are known resources that can't be identified using
Sharon> the suggested method, then we can expand the resource
Sharon> type. Things that come up in the field can use the
Sharon> alarmVariable table as either an alternative or to provide
Sharon> clarifying objects.
	
This does not sound simpler to me. Adding a new resource type requires
to spin the document and it also requires that the resource is indexed
by a simple integer. The other approaches you mention above seem to
contradict your desire for simplicity in the management application.

/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/>