Subject: test mib and atm testmib

From: Kaj Tesink <[email-masked]>
Date: Mon, 08 Mar 1999 18:44:19 -0500

hi, the comments i received on the test mib and atm testmib
are mostly from bert wijnen who kindly did a quality review.
see attached his comments and my annotations.
there was also a comment from brian hassink on
testMoreInfo point 5 below.
it all seems straightforward so i'll prepare a revision
accordingly. in the absence of other comments i assume that 
the wgs are happy with the specs as is.

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.

>
>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

>
>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?

>
>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

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

done

>
>comments on draft-ietf-atommib-test-04.txt
>------------------------------------------
>
>0.Good, this one compiles
>
>1.Pls add some comment for RFC-editor to properly assign OID
>  to MODULE-IDENTITY. Pls decide for mib-2 or experiemental.
>  And, omit the IMPORT for the one you decide against.

right

>
>2.Seems that security section needs work

ok

>
>3.IPR statement needed if target is standards track

ok

>
>4.I have not had time to do more review of this MIb other than
>  the proces/admin type of checks listed in 0-3.

ok

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

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

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