Re: Draft MIB Review Guidelines

[Andy Bierman <abierman@cisco.com>]

At 01:00 AM 11/8/2002 -0800, C. M. Heard wrote:
>Colleagues,

I read through the draft and it looks very good.
There are probably some more style-guide type details to include.
Here are a few I can think of now:

DESCRIPTION clause for fooEntry:
  - should mention how the table is populated
    - if read-create, then do mgmt apps and agent both create rows?
    - if SPARSE-AUGMENTS, what is the sparse condition?
  - any external objects in the INDEX clause should be explained,
    wrt/ to any relationship to objects in this table
  
DESCRIPTION clause for fooRowStatus
  - mention which objects (if any) have to be set to valid values
    before the row can be activated
  - mention if any cascading tables have to be populated with
    related entries before this entry is activated

DESCRIPTION clause for StorageType objects
  - (from 2579) Every usage of this textual convention is required to
     specify the columnar objects which a permanent(4) row must
     at a minimum allow to be writable.

Nits to check for:
  - Use of TimeTicks when TimeStamp is actually appropriate
  - Use of Counter32 when semantics not rigidly followed;
    should be Gauge32 or Unsigned32 instead

Andy


>Back in August, when I stirred up the controversy over whether
>TCs should get to remove syntactic constraints of base types,
>Bert Wijnen asked for a volunteer to write a CLR document.
>That volunteer turned out to be me.  The project ended up
>morphing into a MIB review guidelines document, which turned
>out to be quite a bit harder to organize that I thought it
>would be.  I've been struggling to get it written ever since.
>
>I finally have a draft that is ready for people to poke sticks
>at.  It's far from finished, is probably inadequately
>proofread, and most certainly reflects my own idiosyncratic
>prejudices.  Still, I'd still appreciate any comments that you
>could make, especially if you have suggestions on what
>additional stuff should go in it, what should get cut out, and
>what needs to be reorganized.  [I can already see one thing I
>missed:  something needs to be said about specifying persistency
>of dynamically created rows across reboots.]  The hope-for is
>that with your help I can cobble together something that would
>be suitable for publication as a BCP.  Since it's way past the
>I-D deadline, I'm attaching the draft (such as it is) to
>this e-mail.
>
>Thanks in advance for your help.  Any comments, especially
>negative ones, will be welcome.
>
>I will be away on travel until after Thanksgiving and
>consequently in only sporadic e-mail contact, so a slow
>response does not mean that I'm ignoring you.
>
>Mike