[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-ops-mib-review-guidelines-02.txt is now available
Here are some comments from Keith McCloghrie, forwarded
with his kind permission. They were made some time ago
about the now-obsolete -01 version, but apply equally well
to the current -02 version. Anyone who thinks that these
issues warrant making corrections to the guidelines document
should send an e-mail message to this list, preferably
with proposals for specific changes to the text.
---------- Forwarded message ----------
Date: Wed, 26 Feb 2003 09:23:45 -0800 (PST)
From: Keith McCloghrie <email@example.com>
Cc: Keith McCloghrie <firstname.lastname@example.org>, email@example.com
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
So, I thought I'd check out what it says in:
unfortunately, it wasn't very helpful. It only says OCTET STRINGs must
be more restrictive than (0..65535), and includes among the examples:
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
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.
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
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.