Subject: RE: ResourceType & ResourceId

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 17 Dec 2001 14:21:39 -0500

hi

If we're worried about extensibility, we can always
register with IANA. Until we enrich the SMI, an integer
identifier should model most, if not all, resources.

It's much easier to say that we don't know what a resource
under alarm might be, so let's just use a pointer. I think
we add more value if we think about what resources will alarm
and provide a framework to describe them consistently and
the ability to extend it as required.

A compromise between the two approaches might be to keep
the resource type object and then turn the ID into a RowPointer
with, as you mentioned, specific guidance on how that object
MUST be used for specific known resource types. It's less
efficient than an integer, but efficiency isn't everything.
This approach has the advantage of more meaningful interpretation
of the "other" type, while still providing enough of a framework
that people might follow it.

Sharon

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Monday, December 17, 2001 12:54 PM
To: Chisholm, Sharon [CAR:NM50:EXCH]
Cc: [email-masked]; [email-masked]
Subject: Re: ResourceType & ResourceId

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 18 Dec 2001 12:08:45 +0100

>>>>> Sharon Chisholm writes:

Sharon> If we're worried about extensibility, we can always register
Sharon> with IANA. Until we enrich the SMI, an integer identifier
Sharon> should model most, if not all, resources.

It does not. Not all tables are indexed by a small integer.

Sharon> It's much easier to say that we don't know what a resource
Sharon> under alarm might be, so let's just use a pointer. I think we
Sharon> add more value if we think about what resources will alarm and
Sharon> provide a framework to describe them consistently and the
Sharon> ability to extend it as required.

I welcome to name a list of typical resources in the description
clause. I want however retain the flexibility to refer to other
resources as well.

Sharon> A compromise between the two approaches might be to keep the
Sharon> resource type object and then turn the ID into a RowPointer
Sharon> with, as you mentioned, specific guidance on how that object
Sharon> MUST be used for specific known resource types. It's less
Sharon> efficient than an integer, but efficiency isn't everything.
Sharon> This approach has the advantage of more meaningful
Sharon> interpretation of the "other" type, while still providing
Sharon> enough of a framework that people might follow it.

I would argue that the resource type object in this case is just
overhead since it is clear from looking at the OID what the resource
type is. I suggest to use a RowPointer which appropriate text in the
description clauses what typical resources are (in the IETF MIB
standards).

We should encourage people to point to IETF standards describing
resources but not prevent them from pointing to resources defined
somewhere else if either the IETF standards do not cover some
resources or some IETF standards are just not supported in a given
environment.

/js