home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / entmib / entmib-minutes-95dec.txt < prev    next >
Text File  |  1996-06-03  |  7KB  |  174 lines
  1. CURRENT MEETING REPORT
  2.  
  3.  
  4. Reported by Bob Stewart, Cisco 
  5.  
  6. Minutes of Entity MIB Working Group
  7.  
  8.  
  9. 4 December
  10.  
  11. Keith reviewed the charter.
  12.  
  13. Keith Reviewed our requirements:
  14.  
  15.     -   We clarified that "avoiding architectural specificity" means
  16.         hardware.
  17.     -   Do we need more specific functional requirements?
  18.         .  Repeater MIB has found its own solution.
  19.         .  Coordination across working groups will happen by default.
  20.         .  Some want only physical information in MIB, some want only
  21.            logical, some want both with relationships.
  22.         .  We will reconsider IP-only as we go.
  23.  
  24. Keith presented an overview of the issues from overheads, deferring
  25. discussion:
  26.  
  27.    1.   Remove references to SNMPv2 context
  28.    2.   MIB structure
  29.    3.   Indexing
  30.         -  Consider Johnson Index for physical
  31.         -  What about logical entities?
  32.         - Scope of index value assignments
  33.           .  Across multiple communities
  34.           .  Across reboots/reconfiguration
  35.     4.  Containers and containees
  36.     5.  Standardized values for entPhysicalCLass
  37.     6.  Individual objects
  38.         -  deletions
  39.         -  additions
  40.     7.  Suitability of usage examples
  41.     8.  Conformance statements
  42.     9.  Traps
  43.    10.  Full or subset information
  44.    11.  Definition of logical entity
  45.    12.  Relationship to sysOrTable
  46.    13.  Maria's physical contains table
  47.  
  48. Andy Bierman presented a similar issues list from overheads, with discussion:
  49.  
  50.     -   Inserted an impromptu overview of the MIB.
  51.     -   Add conformance to issues list.
  52.     -   Change entPhysTable indexing?
  53.     -   Add notifications to issues.
  54.     -   Relative indexing among multiple agents is a global issue.
  55.         .  Subset views must be possible.
  56.         .  Must there be a view with everything in it?
  57.         .  No, it may not be practical or possible.
  58.         .  This is an issue.
  59.     -   Tree of types:
  60.         .  How deep and how detailed is it?
  61.         .  Drop it?
  62.         .  It's needed, as OIDs or enumerations, not strings.
  63.         .  It can get very large and change too much.
  64.         .  It may have to coordinate with other standards.
  65.         .  To keep control it should have "unknown", "other", and
  66.            limited enumerations.
  67.         .  It must be extensible, which works for sysObjectId.
  68.     -   Last change timestamp:
  69.         .  Need more detail?
  70.         .  Need less detail?
  71.         .  It's a flag to pull everthing, indicated by one timestamp.
  72.         .  Logical and physical may change separately and applications
  73.            may be focussed.
  74.         .  Changes are rare, pulling all is not burdensome.
  75.         .  Logical may change multiple times/second.
  76.         .  Perhaps one logical and one physical is best.
  77.     -   Fix index ordering.
  78.         .  One implementation done with logical first for manager and
  79.            agent.
  80.  
  81. The group worked on the issues:
  82.  
  83.     -   Should we remove SNMPv2 or delay?
  84.     -   Security is an issue if we end up with only community strings.
  85.     -   Is a solution for SNMPv2 close?  Context is a major v2 issue.
  86.     -   Perhaps MIB view can replace context?
  87.         .  View is wrong concept.
  88.         .  Are logical entities separate views?
  89.         .  Avoid word "context."
  90.         .  Make logical entity the same as local entity.
  91.         .  No, too much overlap.
  92.         .  Call it a naming scope.
  93.     -   Some manager must be able to discover everything.
  94.     -   Concensus is no delay, remove SNMPv2 references.  We must resolve
  95.         terminology and definitions.
  96.     -   Community strings are becoming too overloaded.
  97.         .  We need a stronger admin framework.
  98.         .  Change will come.
  99.         .  We are at more detail than SNMPv2, which pushes back on v2.
  100.         .  We need a good definition of naming scope, generic to SNMP
  101.            version.
  102.     -   We presently have multiple logical entities in a single naming
  103.         scope and can't change that.
  104.         .  If we don't limit what is in a scope, we must provide access
  105.            access to information.
  106.         .  Each name scope must have its own sysCOntact, values may be
  107.            same or different.
  108.     -   We continued with much discussion and confusion.
  109.     -   Andy Bierman took an action item to write our definition of a
  110.         logical entity or context and call it a naming scope.
  111.         .  Are naming scopes static?  Defined in a MIB document?  By
  112.            a vendor?
  113.         .  Should ther be exactly one or multiple logical entities per
  114.            naming scope?
  115.         .  We define rules for naming scope, implementor chooses how
  116.            to group logical entities.
  117.         .  Operational context is defined by a PDU, with multiple
  118.            naming scopes at the discretion of the implementor.
  119.  
  120.  
  121. 5 December
  122.  
  123. Jeff Johnson presented a hierarchical indexing idea:
  124.  
  125.     -   It no longer applies to logical.
  126.     -   He's tired of pushing it.
  127.  
  128. Maria Greene presented a proposal:
  129.  
  130.     -   The problem is determining the containment tree and predicting
  131.         indexes.
  132.     -   Add a containment table and a relative position object.
  133.     -   Idea is based on implementation experience.
  134.     -   It's easy to know what's been plugged in but hard to know what
  135.         it's plugged into.
  136.     -   Consensus was to adopt this proposal.
  137.  
  138. We discussed the Johnson index:
  139.  
  140.     -   It's too long.
  141.     -   You can't always know what's above you which may be a problem for
  142.         a subagent.
  143.     -   It's too hard, such as coordinating with ifIndex.
  144.     -   Even arbitrary indexes require coordination.  With a Johnson
  145.         index you know your own numbers and those below you.
  146.     -   It's too hard to pick apart OIDs.
  147.     -   Use Johnson index as first index of containment table, second as
  148.         relative in parent.
  149.     -   If it's an OCTET STRING the number of siblings is limited to 255.
  150.         If it's an OID the depth is limited.
  151.     -   Is OID encoding plausible?  Is the depth enough?  Only 255 wide
  152.         is too narrow.
  153.     -   Advantages are a single table and compact encoding.
  154.     -   A Johnson index helps managers build a name.
  155.     -   RMON-2 has something similar and optimizes with a local small
  156.         index to decrease PDU size and index complexity.
  157.     -   It won't perform.
  158.     -   The consensus was no Johnson.
  159.  
  160. We discussed class types:
  161.  
  162.     -   Switch to an enumeration with a small list.
  163.     -   Not happy with short list, will investigate standard lists and
  164.         report.
  165.     -   Use vendor value for detail.  Leave out "other" to avoid becoming
  166.         useless.
  167.  
  168. Miscellaneous parting shots:
  169.  
  170.     -   Someone volunteered to do an example of a repeater/bridge/router.
  171.     -   Add a trap for lastChangeTime to sense when rows come and go.
  172.     -   Add one lastChangeTime scalar.
  173.  
  174.