Editor's note:  These minutes have not been edited.

Date: Tue, 25 Jul 1995 16:29:54 -0400
From: Bob Stewart <[email protected]>

Minutes of the Entity MIB BOF
Stockholm IETF
17 July 1995

Chaired by Keith McCloghrie, Cisco Systems

Agenda:

       Present requirements
       Discuss requirements
       Present potential solution
       Discuss potential solution
       Discuss future work

Keith presented a statement of the problem:

   -   Need for multiple instances of a MIB occuring more often.
   -   Should use multiple SNMPv2 contexts rather than change MIBs.
   -   Context represents MIB in a logical entity.
   -   One agent may support multiple entites or not, difference
       is not important.
   -   Useful to relate to one or more physical entities

Requirements:

  1.   Find entities in one place.
  2.   Find relationship between physical and logical.
  3.   Single and multiple agents.
  4.   SNMPv1 and SNMPv2.
  5.   Minimimalist approach:
       -  Read only.
       -  Avoid specific system architectures.
       -  Can't agree - leave it out.


Discussion of requirements:

   -   This is not the subagent problem.
   -   For SNMPv1 IP address identifies agent and community string
       identifies context.
   -   Cost justified by existence of need.
   -   Why read-only?  We don't understand configuration well enough.
       Interface table can't create entries.  Adding entities difficult
       and doesn't reflect reality.  Some want to use it to constrain
       reality.

Andy Bierman presented a potential solution, and discussion became
interleaved with the presentation:

   -   Internet Draft available as "draft-bierman-entmib-mib-00.txt".
   -   Non-goals to include chassis-specific components or to draw
       physical pictures.
   -   IP-centric for SNMPv1.  For other transport domains, use SNMPv2.
   -   Presented from Draft by examples.
   -   Values for entLogicalType not clear yet.
   -   Standardized physical class to be added (e.g. repeater, router).
   -   Dependent on SNMPv2 definition of a context.
   -   Issues exist regarding relationship of contained, independent
       agents to consistency of Entity MIB information.
   -   Consider reverse mappings for IfMappingTable and
       AliasMappingTable.
   -   Why solve problem for Interfaces MIB and not in general?  Need
       suggestions for generic approach.
   -   Add objects for more information if generic enough.
   -   Should "removeable" go further or go away?
   -   What is source of MIB information?  Hard code?  Operator entered?
       Too much if latter?  Interaction between software modules?
   -   Want interface for adding entries?  No.  All we want for now is
       visibility without solving the entire problem.
   -   Why is setting up this working group different from setting up
       one for subagent technology?  This sets a standard for
       interaction between NMS and agent, not among agents or pieces
       of agents.
   -   Can we do physical without logical or logical without physical?
       Either can degenerate to simplest contents.
   -   Main requirement is list of logical entities and way to get to
       them.  MIB does that.  Physical part could be removed.
   -   Where is the line for using different contexts and using
       arbitrary integers for indexing?  For example, ifTable
       could be scalars.  We could add repeaterID.

The final consensus of the meeting was to request formation of a working
group.  The Area Director appeared positive.

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.