Re: snmpconf Comments on BCP-09

HI,

I appreciate you working on trying to find common ground.

Here are the concepts that I don't believe that the BCP
expresses correctly:
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
   assigned.
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
   other concepts.
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
   established.
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.

Regards,
/david t. perkins