Subject: Posting of <draft-ietf-ifmib-testmib-05.txt>

From: Kaj Tesink <[email-masked]>
Date: Fri, 09 Apr 1999 20:03:42 -0400

Hi,

Please post the attached as draft-ietf-ifmib-testmib-05.txt.

The key changes were as announced on the mailing list. See below. Note that
draft-ietf-atommib-test-05.txt depends on this.
Any final comments?

Thanks,

Kaj

---------------------------------

>>
>>comments on draft-ietf-ifmib-testmib-04.txt
>>-------------------------------------------
>>
>>0.typo for testTarget MAX-ACCES  => MAX-ACCESS
>>
>>1.The module name would probably better to be IF-TEST-MIB as opposed
>>  to just TEST-MIB. The latter has too much chance for conflicts.
>>  I think I would accordingly prefix all descriptors with ifTestXxxx
>>  instead of just testXxxx
>
>i have pointed out that this change was made deliberatedly in the past
>to allow non-if tests as well.
>

i have not made further changes on this

>>
>>2.I suggest that the WG decides if they want this on the standards
>>  track or under experimental and then use mib-2 or experimental
>>  accordingly.
>>  And, omit the IMPORT for the one you decide against
>
>standards track process will be followed
>
>>
>>3.For testIndexNext you may want to add a note that each GETNEXT or
>>  GETBULK for this object will also decrease the value, and so it
>>  is quite possible that (large) gaps will occur.
>
>will do
>
>>
>>4.You state that only one test can be active and that invocation of
>>  a second test will be rejected. Such invocation of a second test
>>  is done by setting another row to active (if I understand it
>>  correctly). Please specify what error-code will be returned in
>>  this case. I think this is best specified in the DESCRIPTION of
>>  the rowstatus.
>
>will copy similar text from elsewhere

see inconsistentValue text

>
>>
>>5.I wonder if testMoreInfo is supposed to be human readable?
>>  If so, some form of UTF8 string is a better syntax I think.
>
>brian hassink's point was:
>
>These MIBs are nice to see. In a recent project, we had several concerns
>with the
>test objects defined by the IF MIB (i.e. notification of a completed test to
>avoid polling, logging of test results to avoid loss due to a subsequent test,
>and test parameters) and opted to write our own test objects and procedures
>in an
>enterprise MIB. These concerns appear to have been addressed by the
>proposed test
>MIB. One small comment is that "testParameters" may be a slightly more
accurate
>name for the "testMoreInfo" object.
>
>my understanding is that the syntax and object descriptor was choosen
>the way it is to allow maximum flexibility, e.g., to allow non-human-readable
>info. testParameters may also constrain it to pointers or something like that.
>based on that understaing my suggestion is to keep as is,
>but i'm open to other interpretetations.
>
>any other views?

i havent made any changes on this

>
>>
>>6.Would a DEFVAL of 'none' not be a good deault for testResult?
>
>done
>
>>
>>7.There is no storage type for testTable. Does that mean that all
>>  entries are volatile, except for the exception that you stated
>>  in case a test causes a re-start of the agent? Might be good
>>  to say something about it. Mmm... you state it in testTableMaxSize.
>>  Seems it belongs in the table DESCRIPTION too.
>
>done
>
>>
>>8.Testcapabilities is nice to list all capabilities.
>>  It does not indicate though which tests can be applied to which
>>  targets. Is that something that a manager should just try and
>>  find out by tryal and error?
>
>might become a very long list

i havent made any changes on this

>
>>
>>9.If this MIB goes onto standards track, then you also need to add
>>  an IPR section (see RC2026, sect 10.4).
>
>done
>
>

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

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

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