Subject: draft-ietf-ifmib-testmib-06.txt Posting

From: "Bert Wijnen" <[email-masked]>
Date: Mon, 20 Dec 99 15:31:55 CET

Ref:  Your note of Tue, 07 Dec 1999 20:23:34 -0500

Subject: Re:   draft-ietf-ifmib-testmib-06.txt Posting

Thanks for making the changes. It now compiles clean.
Sorry if this sounds like nitpicking, but....
I still have some comments on draft-ietf-ifmib-testmib-06.txt
Do you think you can address those? That would be nice.
I am also still a bit worried about the name of testMIB. It is
a very easy target for collision. I did read your explanation
and so I understand why it is not called ifTestMib... yet...??

- Some indentation issue in section 3. Starting at the 2nd para in
  5th bullet, it should be back to the left margin. Bullet 5 has only
  one para.

- I doubt that Maria Greene's email address is correct, is it?

- Explian to me why we start with a big number in the tetsIndexNext
  object. Why would we not start with 1 and let it increase?

- testResultTimestamp.
  I guess, it could have a defval of 0 too.

- testCode
  I am still a bit confused by the DESCRIPTION clause. It seems to
  indicate that the value could be an integer, but it clearly cannot
  be so, because the syntax is OBJECT IDENTIFIER
  I think I am confused because of the first sentence.
  If it used "ptr to a code" instead of "a code" then I would
  understand it better I think.
  Again, a defval of zeroDotZero might be handy.
- testcode
  referes to RFC1903, should refer to RFC2578.
  Yep... that what you get if it takes a long time to recycle an I-D,
  then the rest of the world moves on ;-)

- testOwner
  Mmm... you may want to point to the DESCRIPTION clause of testTable
  which explains this "ownership". Also you may explain that having
  "ownership" does not guarantee that another manager cannot start
  the test or set/change the test parameters. This ownerstring just
  makes it possible for cooperating managers to do the right thing.
  Maybe that should be made clear(er)?
  Maybe it is OK to just change "required to invoke..." into
  "to invoke....".
- testOwner
  It should not longer reference RFC2233, should it?
  Besides, RFC2233 is being obsolted and the new MIB has deprecated
  OwnerString, so you do not want to reference it here I think.

- testRowStatus
  I guess I mentioned in earlier comments that a defval of createAndWait
  is not correct. Now you have a defval of notReady. That seems wrong
  too. For read-create tables, I think that this object type cannot
  (whould not) have a defval. It just depends on how the row is
  created (at least that is how understand the RowStatus TC in RFC2579.

Bert