[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snmpconf Comments on BCP-09
I appreciate you working on trying to find common ground.
Here are the concepts that I don't believe that the BCP
1) scaling - when the number of ports was 2 per box then poorly
designed MIBs, SNMP agents, and/or management apps didn't cause
too much of a problem. When it increased to 10-50 per box,
things got sluggish. Now with some boxes having 100s of
ports, then bad designs and practices result is a non-workable
approach. And with virtual stuff layered on top of the
physical, there can be many tables where there or 100s
and maybe 1000s or instances.
2) configuration persistence (and StorageType) - the point is that
managing persistence of configuration is very system specific,
and that the StorageType model doesn't fit reality. Don't
encourage a MIB design pattern that is not workable.
3) notification terminology - it seems like almost everybody gets
this messed up. And I'll tell you, until I wrote the "Understanding
SNMP MIBs" book, I was just as confused (and/or sloppy) as
everyone else. The document really doesn't read as if
the document authors got it all worked out before starting.
The result, even with some corrections incorporated, is
less than desirable.
4) Section 3.10.2 is still factually incorrect, and paragraph
3 is still majorly factually incorrect. The following statement
"InformRequest PDUs. when compared to TRAP PDUs, have an
inherent advantage when the concern is the reduction of
unnecessary from the system generating NOTIFICATION-TYPE
data, when in fact retransmission, of this data is required."
and the remainder of the paragraph mashes together two
separate issues, resulting is nonsense. The title of the
section is "Limiting unnecessary transmissions of notifications".
In this category, I would expect to see the MIB design
issue of designing notifications (using the NOTIFICATION-TYPE
construct) so that one notification can be sent to report
on many events, and to dampen the reporting of events
due to a flapping situation (a hysterics mechanism such as
that found in RMON). Instead, a side trip is made into the
separate issue of using Informs vs Traps.
5) Designing management apps that use sets - the SNMP protocol is
not designed to return "semantic" (that is, application layer)
errors to a management application. This results in a tight
coupling between the semantic knowledge that must be understood
by a management application designer. This requires that
management applications be designed so that "sets never fail".
Because if they do fail, a management app cannot determine
via SNMP why the set failed. MIB designers can lessen the
burden on management apps designers (and agent designers)
so "sets never fail", except under well defined situations
or when memory resources on a managed system are at total
exhaustion. Section 3.11, covers this aspect of management
application design. Unfortunately, a sentence in the second
paragraph uses the term "incumbent", which means "duty" or
"obligation". Management apps have no such duty. The cause
and effect and the resulting actions needed to be taken
to counter the effect are not correctly distinguished and
6) Fine grained access control assignment - a desirable property
is to allow management apps to create resource instances
via an SNMP set, and to gain "exclusive" or "owner" access
as found in file creation operations found in many operating
systems, such as the Unix variants. However, the VACM-based
access control is VERY different than Unix-like file access
control. A design pattern was introduced in the MIB modules
from the DISMAN WG which attempted to mimic the Unix-like
access control behavior on creation. This design pattern
is flawed (and many have not yet realized it). Please
describe the objective, show the MIB design pattern and
describe how it is flawed. (Note that another design pattern
to give fined grained access control is found in table
usmUserTable in RFC 2574.) The pluses and minuses of
the design pattern used there should be pointed out.
Finally, an improved MIB design pattern should be presented.
7) Usage of OwnerString - the advantages and disadvantages of
the OwnerString TC should be described without muddling with
8) SNMPv3 Contexts - section 3.13.2 totaly misses the point about
contexts, which is that contexts in most, if not all cases, are
the result of the "failure by a MIB designer to correctly predict
the future". Contexts are "an escape mechanism to add another
level of indexing". The entity logical table was not really
designed to support context discovery. And it is not required.
Note that the last sentence of section 3.13.2 is factually
incorrect in its assertion that context are administratively
9) the problems with the description of authentication notification.
First, it is specified to be in RFC 1215, and implied to be used
in only SNMPv1. The current definition of the authentication
notification is found in RFC 1907. And it is generated when
SNMPv1, SNMPv2, and SNMPv3 (with USM) result in authentication
failures. Now, it is the case that the notification was not well
designed, and in some deployments due to improper agent design,
and/or poor choice of security configurations, that its generation
should be turned off. This section should explain each of these
factors instead of repeating the herd mentality of "always
turn of generation". If the notification is not turned on,
then the objects snmpInBadCommunyUses, usmStatsUnknownUserNames,
usmStatsNotInTimeWindows, and usmStatsWrongDigests must be
monitored to determine authentication failures.
Sorry, but I don't have more time for feedback today. There are lots
of words that I could say about the fallacy of believing in the
reliable delivery of notifications.
/david t. perkins