Subject: Non-member submission from [Kaj Tesink <[email-masked]>]

From: "Ted Brunner 503.627.1317" <[email-masked]>
Date: Fri, 04 Dec 1998 10:54:19 -0800

Ted Brunner		Video and Networking Technology
			Tektronix
			MS 50-490
[email-masked]	14150 SW Karl Braun
503.627.1317		Beaverton OR 97005	

------- Forwarded Message

Message-Id: <9812041356.AA23832@joker>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Fri, 04 Dec 1998 13:55:43 +0000
To: Dawn Xie <[email-masked]>, [email-masked],
        [email-masked]
From: Kaj Tesink <[email-masked]>
Subject: Re: testMib question
In-Reply-To: <[email-masked]>
References: <9812012110.AA11291@joker>
 <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

At 10:47 AM 12/3/98 -0500, Dawn Xie wrote:
>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. 

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

>
>-- Dawn Xie
>Dawn Xie wrote:
>> 
>> 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
>> >
>> > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>
>--
> 

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

Kaj Tesink
Bellcore
Email  [email-masked]
Tel    732.758.5254
Fax    732.758.2269
Postal 331 Newman Springs Rd
       Red Bank, NJ 07701
       USA

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

------- End of Forwarded Message