Subject: Re: testMib question

From: Dawn Xie <[email-masked]>
Date: Wed, 02 Dec 1998 10:49:00 -0500

What we did is mixing with the rowStatus. I guess adding a new control
handle is fine. Mixing with operation status is confusing and seems
not a good approach. 

-- Dawn Xie
   [email-masked]

Kaj Tesink wrote:
> 
> hi,
> 
> i'm in the process of revising the test mib based on
> previous quality review. this mib is necessary to
> allow media and system-specific tests. the specification
> that depends on this is the atm test mib.
> 
> the quality reviewer produced a comment that i want to run
> by the list:
> 
> - currently tests are started through setting testRowStatus
>   to active
> - the review suggests that it may be preferable to keep the
>   test manipulation separate from the row manipulation for
>   implementation reasons
> - i have played around with several solution combinations
>   and think that the suggestion is reasonable. there are two
>   possible fixes:
>   i) change the testResult object to include a start/stopTest
>      capability
>   ii) introduce a new column say testHandle that can
>       be idle(10, start(2), abort(3)
> 
> i'm inviting comments on all possibilities. interactions
> between testRowStatus, testResult (and testHandle) will have to
> be described carefully. note that these
> changes all necessitate changing the atmTestMib as well.
> in the absence of comments i'll put option ii) in the spec
> and produce an update of the atmTestMib.
> 
> kaj
> 
> ps since the previous draft was expired i'll attach it below.
> 
>   --------------------------------------------------------------------------------
> 
>    Test.rfc   Name: Test.rfc
>               Type: Plain Text (text/plain)
> 
>   --------------------------------------------------------------------------------
> 
> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> 
> Kaj Tesink
> Bellcore
> Email  [email-masked]
> Tel    732.758.5254
> Fax    732.758.2269
> Postal 331 Newman Springs Rd
>        Red Bank, NJ 07701
>        USA
> 
> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

---

From: Dawn Xie <[email-masked]>
Date: Thu, 03 Dec 1998 10:47:25 -0500

We are making a big issue of this small item, but I guess any implementation is
just full of these technical details.

Now I remerber why we used the rowStatus, without having a seperate control
object: in our implementation, we agreed on an implied requirement that whenever
a user creates a row in this table, s/he wants the device to execute the test
right away. This implied logic makes the implementation easier:
1. The order of the table matches the execution sequence of the tests
2. easy to clean up the table: just to flush out the oldest entries since they
are always executed first when the table reaches the maximum size.

Adding a separate control object breaks this implied logic. Now user can create
a row, but not executing the test until s/he sets the control object. This makes
the implemention on the devices a little bit more complicated:
1. the device had to maintain a seperate queue for the tests that are actually
"turned on"
2. hard to decide which entried in the table to be flushed out when the table
reaches the maximum size (whether by the order of the row created or by the
order of the tests executed)

Since the table defined in the MIB is really meant for "on demand" tests, not
for "scheduled tests", (in our implememtation, we have seperate Enterprise
tables for scheduled tests), I think it is reasonable to put this implied
requirement to the table. I think it is not necessary to give user the flexibily
with add-on complexity to allow them to create a test in the table, but not
execute the test right away.

In short, my two cents is: keep the current definition but adding explanation
that whenever user creates a test in the table, the test will be executed right
away by the device. 

-- Dawn Xie

--