Subject: Re: REMOPS MIB Indexing

From: [email-masked]
Date: Tue, 23 Mar 1999 05:20:47 -0500

Harmen,

>Could you elaborate how a value for the test ID is generated?
>(Forgive me for asking; I wasn't at the meeting).

It was recommended that the test and increment object in each MIB be
used. In the DISMAN-PING-MIB this is pingSpinLock. Basically a
management appl would get the current value and then do a set on the
object with the value returned. If at the agent side the value of the
set matches that of the test and increment object then the value of
the object is increased  by 1 and the set succeeds. The mgmt appl can
then used the value of the original get as a test ID.

Ken

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 23 Mar 1999 12:10:56 +0100

>>>>> wkenneth  writes:

wkenneth> I actually voted for this at the time, but would like to
wkenneth> change my vote for just using ownerIndex and testId. After
wkenneth> the meeting I was discussing this with a few folks and
wkenneth> realized that leaving the destination address in limits the
wkenneth> size of a symbolic name as an destination address to
wkenneth> whatever portion of the 128 octet instance ID maximum that
wkenneth> would be available. Does anyone object to using just
wkenneth> ownerIndex and testId for the indexing?

I have not followed the discussions lately so my comment may be out of
scope. Anyway, what I would like to see is an indexing scheme which
allows to start "remote operations" via the Scheduling MIB. And this
means we will have cross references to MIB rows. Therefore, having
"semantically useful" index components (such as names) is would be
very convenient.

In other words, I suggest to use:

          pingOwner           SnmpAdminString, -- index
	  pingName	      SnmpAdminString, -- index
          pingHostAddress     HostAddress,
          pingPacketSize      Integer32,
          pingTimeOut         Integer32,
          pingProbeCount      Integer32,
          pingOperStatus      OperationStatus,
          pingRowStatus       RowStatus

I also have problems with the fact that the activation of a row also
starts the ping process. The reason here is that a notInService state
has a timer associated with it. It is therefore not possible to have a
pre-configured pingTable entry staying around for a longer period of
time. But this probably belongs into another thread...

							Juergen
-- 
Juergen Schoenwaelder  [email-masked] 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: Bob Stewart <[email-masked]>
Date: Thu, 25 Mar 1999 15:59:25 -0500

>then used the value of the original get as a test ID.

Are applications required to use the spin lock value as an index?  If so,
how is that enforced?  If not, the spin lock is of marginal value.
Applications will still need code to handle collisions where they try to
create an entry that's already been created.

Note that using the spin lock will suggest numbers that are unique across
all owners, which isn't necessary, while having a spin lock per row is
rather overdoing it.

Overall, if an arbitrary integer is to be used it's generally best either
to suggest that applications use a random number or to supply a "next
index" per row that applications can read first.

No matter what you do, good applications must code for the possibility of a
collision and retry the suggested number selection algorithm if they get one.

I'd prefer the random number approach.

Actually, I'd prefer just biting the bullet and letting people name their
test entries with a text string.  That way they can supply whatever sorting
or site-specific content seems appropriate to them, and have a meaningful
identification that people can remember and use or even predict.  That's
the direction we've been going in other MIBs.

	Bob