draft-ietf-ops-mib-review-guidelines-01.txt (fwd)

["C. M. Heard" <heard@pobox.com>]

Mib Doctors -

Here are some comments from Keith McCloghrie, forwarded
with his kind permission.

Mike Heard

---------- Forwarded message ----------
Date: Wed, 26 Feb 2003 09:23:45 -0800 (PST)
From: Keith McCloghrie <kzm@cisco.com>
To: heard@pobox.com
Cc: Keith McCloghrie <kzm@cisco.com>, bwijnen@lucent.com
Subject: draft-ietf-ops-mib-review-guidelines-01.txt

Mike,

I was just asked to advise/adjudicate between a (local) MIB submitter
who wants to use:

  OCTET STRING (SIZE(0..480))

and a (local) MIB reviewer who is working with a set of guidelines
which say that OCTET STRINGs should be limited to a maximum length of
255 octets.

So, I thought I'd check out what it says in:

   draft-ietf-ops-mib-review-guidelines-01.txt

unfortunately, it wasn't very helpful.  It only says OCTET STRINGs must
be more restrictive than (0..65535), and includes among the examples:
(0..1024)

In the past, I have advised people to split a (fixed-length) string of
1024 octets into multiple objects, e.g, four objects each of length
256 octets.

The rationale for this, of course, is the 484-octet message length,
and I note that this is still maintained in RFCs 3411, 3412 and 3417.
The community didn't bite the bullet and say: SNMPv3 agents MUST
support messages of size 1472 octets.  As a result, MIB objects which
will not fit in a 484-byte message are not implementable by all
SNMP-compliant agents.  It is undoubtedly a bad idea to allow MIBs to
be defined that are not implementable by an SNMPv3-compliant agent.

Keith.

PS. I intend to look at  draft-ietf-ops-mib-review-guidelines-01.txt
in more detail, as and when I get the chance, but in flicking through
it I did notice one other thing to comment on:

   The consensus of
   the current pool of OPS Area MIB reviewers is that the SMIv2
   recommendation to limit descriptors, TC names, and labels to 32
   characters SHOULD be set aside in favor of promoting clarity and
   uniqueness and that automated tools such as MIB compilers SHOULD NOT
   by default generate warnings for violating that recommendation.

I am of the opposite opinion.  It is already frequently inconvenient
to write email messages with reasonably-even length lines in which one
refers to MIB objects by their descriptors, e.g.,
snmpWarmStartNotificationGroup, where the choice is to leave lines half
empty, or to have them overflow the right margin like this: vacmSecurityToGroupStorageType.

Both of the above descriptors are less than 32 characters.  The
situation will be impossibly worse with 64 long descriptors to the
extent that each descriptor will just about need its own line.
Such inconvenience just isn't worth it.  It just takes more
discipline to define descriptors that are less than 32 characters.
Despite them being officially called "descriptors", we use
them as "names", and names do not need to include a description,
despite Microsoft's horrible lack of formatting rules for file names.
Anyway, even 64 characters are not long enough to include a full
description.

In fact, abbreviated names are not evil; we use them all the time.  For
example, why are you C.M.Heard -- why don't you spell out what the C
and the M stand for ?? :-).

There's also another reason: if there is a one character difference
between two descriptors, it's much easier to detect such a difference
with shorter descriptors, i.e., with longer descriptors, there's a
greater risk of mistaking the descriptor of one object for the
descriptor of another with a similar spelling.  Let's not increase the
chances of confusion/ambiguity.  Let's have more discipline.

PPS. I've cc-ed Bert.  Feel free to forward this message if you wish to.