Subject: testMib question

From: Kaj Tesink <[email-masked]>
Date: Tue, 01 Dec 1998 21:10:26 +0000

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.

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

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: 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:
>   --------------------------------------------------------------------------------
> 
>    Test.rfc   Name: Test.rfc
>               Type: Plain Text (text/plain)
> 
>   --------------------------------------------------------------------------------
>

---

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

--

---

From: Kaj Tesink <[email-masked]>
Date: Fri, 04 Dec 1998 13:55:43 +0000

>that whenever user creates a test in the table, the test will be executed
right

hmm, implementation experience always sounds convincing.
but on your separate queue point, you may have to do that
anyway because of createAndWait. 
however, in the mean time i had constructed the below:

            testHandle   OBJECT-TYPE
                SYNTAX      INTEGER {
                              testOff(1),
                              testOn(2)
                MAX-ACCESS  read-create
                STATUS      current
                DESCRIPTION
                   "Manipulation of the test:
                    - A manager can only start a test when the
                      testRowStatus has the value 'active'.
                    - When all test parameters (testTarget,
                      testType, testMoreInfo and testOwner) have been
                      properly set the test is started by setting
                      testHandle to 'testOn'. This causes the testResult
                      to assume the value 'inProgress' until some other
                      value of testResult is reached.
                    - If the manager sets testHandle to 'testOff' while
                      the test is 'inProgress' the testResult will assume
                      the value 'aborted'.
                    - If the manager sets testHandle to 'testOn' while
                      the test is inProgress then this action will
                      not affect the ongoing test.
                    - Details of ongoing or completed tests are
                      reported in testResult and testCode.
                    - When a test attempt produces a testResult
                      value other than 'inProgress'
                      (success, notSupported, unAbleToRun, failed)
                      the agent sets testHandle to 'testOff'.
                    - After test completion the test may be repeated
                      by setting testHandle to 'testOn' again.
                    - A manager may abort ongoing tests or remove
                      completed test information by setting the
                      testRowStatus to 'notInService' or 'destroy'."
                DEFVAL  { testOff }
                ::= { testEntry 9 }

so this indeed causes the indirection that you mention.
i personally dont have a strong opinion on this; if above object is
not used but RowStatus instead some of the conditions can easily be
applied to RowStatus. that is your preference? any other opinions out there?

some minor questions 
- how would you cause a test to be aborted? RowStatus
  to notInService? 
- and from that state a test can be run again by setting
  to active again? 
- and what happens with the test when you set RowStatus to active when
  it is already active (i assume no action)

kaj

>> > ps since the previous draft was expired i'll attach it below.
----------------------------------------------------------------------------
----
>> >               Type: Plain Text (text/plain)
----------------------------------------------------------------------------
----

Kaj Tesink
Bellcore
Email  [email-masked]
Tel    732.758.5254
Fax    732.758.2269