CURRENT MEETING REPORT Reported by Bob Stewart, Cisco Minutes of Entity MIB Working Group 4 December Keith reviewed the charter. Keith Reviewed our requirements: - We clarified that "avoiding architectural specificity" means hardware. - Do we need more specific functional requirements? . Repeater MIB has found its own solution. . Coordination across working groups will happen by default. . Some want only physical information in MIB, some want only logical, some want both with relationships. . We will reconsider IP-only as we go. Keith presented an overview of the issues from overheads, deferring discussion: 1. Remove references to SNMPv2 context 2. MIB structure 3. Indexing - Consider Johnson Index for physical - What about logical entities? - Scope of index value assignments . Across multiple communities . Across reboots/reconfiguration 4. Containers and containees 5. Standardized values for entPhysicalCLass 6. Individual objects - deletions - additions 7. Suitability of usage examples 8. Conformance statements 9. Traps 10. Full or subset information 11. Definition of logical entity 12. Relationship to sysOrTable 13. Maria's physical contains table Andy Bierman presented a similar issues list from overheads, with discussion: - Inserted an impromptu overview of the MIB. - Add conformance to issues list. - Change entPhysTable indexing? - Add notifications to issues. - Relative indexing among multiple agents is a global issue. . Subset views must be possible. . Must there be a view with everything in it? . No, it may not be practical or possible. . This is an issue. - Tree of types: . How deep and how detailed is it? . Drop it? . It's needed, as OIDs or enumerations, not strings. . It can get very large and change too much. . It may have to coordinate with other standards. . To keep control it should have "unknown", "other", and limited enumerations. . It must be extensible, which works for sysObjectId. - Last change timestamp: . Need more detail? . Need less detail? . It's a flag to pull everthing, indicated by one timestamp. . Logical and physical may change separately and applications may be focussed. . Changes are rare, pulling all is not burdensome. . Logical may change multiple times/second. . Perhaps one logical and one physical is best. - Fix index ordering. . One implementation done with logical first for manager and agent. The group worked on the issues: - Should we remove SNMPv2 or delay? - Security is an issue if we end up with only community strings. - Is a solution for SNMPv2 close? Context is a major v2 issue. - Perhaps MIB view can replace context? . View is wrong concept. . Are logical entities separate views? . Avoid word "context." . Make logical entity the same as local entity. . No, too much overlap. . Call it a naming scope. - Some manager must be able to discover everything. - Concensus is no delay, remove SNMPv2 references. We must resolve terminology and definitions. - Community strings are becoming too overloaded. . We need a stronger admin framework. . Change will come. . We are at more detail than SNMPv2, which pushes back on v2. . We need a good definition of naming scope, generic to SNMP version. - We presently have multiple logical entities in a single naming scope and can't change that. . If we don't limit what is in a scope, we must provide access access to information. . Each name scope must have its own sysCOntact, values may be same or different. - We continued with much discussion and confusion. - Andy Bierman took an action item to write our definition of a logical entity or context and call it a naming scope. . Are naming scopes static? Defined in a MIB document? By a vendor? . Should ther be exactly one or multiple logical entities per naming scope? . We define rules for naming scope, implementor chooses how to group logical entities. . Operational context is defined by a PDU, with multiple naming scopes at the discretion of the implementor. 5 December Jeff Johnson presented a hierarchical indexing idea: - It no longer applies to logical. - He's tired of pushing it. Maria Greene presented a proposal: - The problem is determining the containment tree and predicting indexes. - Add a containment table and a relative position object. - Idea is based on implementation experience. - It's easy to know what's been plugged in but hard to know what it's plugged into. - Consensus was to adopt this proposal. We discussed the Johnson index: - It's too long. - You can't always know what's above you which may be a problem for a subagent. - It's too hard, such as coordinating with ifIndex. - Even arbitrary indexes require coordination. With a Johnson index you know your own numbers and those below you. - It's too hard to pick apart OIDs. - Use Johnson index as first index of containment table, second as relative in parent. - If it's an OCTET STRING the number of siblings is limited to 255. If it's an OID the depth is limited. - Is OID encoding plausible? Is the depth enough? Only 255 wide is too narrow. - Advantages are a single table and compact encoding. - A Johnson index helps managers build a name. - RMON-2 has something similar and optimizes with a local small index to decrease PDU size and index complexity. - It won't perform. - The consensus was no Johnson. We discussed class types: - Switch to an enumeration with a small list. - Not happy with short list, will investigate standard lists and report. - Use vendor value for detail. Leave out "other" to avoid becoming useless. Miscellaneous parting shots: - Someone volunteered to do an example of a repeater/bridge/router. - Add a trap for lastChangeTime to sense when rows come and go. - Add one lastChangeTime scalar.