home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 95jul / entmib-minutes-95jul.txt < prev    next >
Text File  |  1995-10-18  |  3KB  |  127 lines
  1.  
  2. Entity MIB BOF (ENTMIB)
  3.  
  4. Reported by Bob Stewart/Cisco Systems
  5.  
  6. The Entity MIB BOF met once at the Stockholm IETF on 17 July.  The
  7. meeting was chaired by Keith McCloghrie.
  8.  
  9.  
  10. Agenda
  11.  
  12.    o Present requirements
  13.    o Discuss requirements
  14.    o Present potential solution
  15.    o Discuss potential solution
  16.    o Discuss future work
  17.  
  18.  
  19. Problem Statement
  20.  
  21. Keith presented a statement of the problem:
  22.  
  23.  
  24.    o Need for multiple instances of a MIB occurring more often.
  25.  
  26.    o Should use multiple SNMPv2 contexts rather than change MIBs.
  27.  
  28.    o Context represents MIB in a logical entity.
  29.  
  30.    o One agent may support multiple entities or not, difference is not
  31.      important.
  32.  
  33.    o Useful to relate to one or more physical entities
  34.  
  35.  
  36. Requirements
  37.  
  38.   1. Find entities in one place.
  39.  
  40.   2. Find relationship between physical and logical.
  41.  
  42.   3. Single and multiple agents.
  43.  
  44.   4. SNMPv1 and SNMPv2.
  45.  
  46.   5. Minimalist approach:
  47.        o Read only.
  48.        o Avoid specific system architectures.
  49.        o If cannot agree---leave it out.
  50.  
  51.  
  52. Discussion of Requirements
  53.  
  54.    o This is not the subagent problem.
  55.  
  56.    o For SNMPv1 IP address identifies agent and community string
  57.      identifies context.
  58.  
  59.    o Cost justified by existence of need.
  60.  
  61.    o Why read-only?  We do not understand configuration well enough.
  62.      Interface table cannot create entries.  Adding entities difficult
  63.      and does not reflect reality.  Some want to use it to constrain
  64.      reality.
  65.  
  66.  
  67.  
  68. Potential Solution and Discussion
  69.  
  70. Andy Bierman presented a potential solution, and discussion became
  71. interleaved with the presentation:
  72.  
  73.  
  74.    o Internet-Draft available as draft-bierman-entmib-mib-00.txt.
  75.  
  76.    o Non-goals to include chassis-specific components or to draw
  77.      physical pictures.
  78.  
  79.    o IP-centric for SNMPv1.  For other transport domains, use SNMPv2.
  80.  
  81.    o Presented from Draft by examples.
  82.  
  83.    o Values for entLogicalType not clear yet.
  84.  
  85.    o Standardized physical class to be added (e.g., repeater, router).
  86.  
  87.    o Dependent on SNMPv2 definition of a context.
  88.  
  89.    o Issues exist regarding relationship of contained, independent
  90.      agents to consistency of Entity MIB information.
  91.  
  92.    o Consider reverse mappings for IfMappingTable and AliasMappingTable.
  93.  
  94.    o Why solve problem for Interfaces MIB and not in general?  Need
  95.      suggestions for generic approach.
  96.  
  97.    o Add objects for more information if generic enough.
  98.  
  99.    o Should ``removable'' go further or go away?
  100.  
  101.    o What is source of MIB information?  Hard code?  Operator entered?
  102.      Too much if latter?  Interaction between software modules?
  103.  
  104.    o Want interface for adding entries?  No.  All we want for now is
  105.      visibility without solving the entire problem.
  106.  
  107.    o Why is setting up this working group different from setting up one
  108.      for subagent technology?  This sets a standard for interaction
  109.      between NMS and agent, not among agents or pieces of agents.
  110.  
  111.    o Can we do physical without logical or logical without physical?
  112.      Either can degenerate to simplest contents.
  113.  
  114.    o Main requirement is list of logical entities and way to get to
  115.      them.  MIB does that.  Physical part could be removed.
  116.  
  117.    o Where is the line for using different contexts and using arbitrary
  118.      integers for indexing?  For example, ifTable could be scalars.  We
  119.      could add repeaterID.
  120.  
  121.  
  122. Conclusion
  123.  
  124. The final consensus of the meeting was to request formation of a working
  125. group.  The Area Director appeared positive.
  126.  
  127.