aa11711;
          31 May 95 22:14 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id
aa11707;
          31 May 95 22:14 EDT
Received: from hp.com by CNRI.Reston.VA.US id aa21630; 31 May 95
22:14 EDT
Received: from hprnd.rose.hp.com by hp.com with ESMTP
     (1.37.109.15/15.5+ECS 3.3) id AA275842902; Wed, 31 May 1995
19:15:02 -0700
Received: from hprnljf.rose.hp.com by hprnd.rose.hp.com with SMTP
     (1.37.109.14/15.5+ECS 3.3) id AA059472897; Wed, 31 May 1995
19:14:57 -0700
Message-Id: <199506010214.AA059472897@hprnd.rose.hp.com>
Received: from localhost by hprnljf.rose.hp.com with SMTP
     (1.38.193.4/16.2) id AA04381; Wed, 31 May 1995 19:19:40 -0700
To: vgmib@hprnd.rose.hp.com
Subject: VG Repeater MIB issues
Date: Wed, 31 May 1995 19:19:40 -0700
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: John Flick <johnf@hprnljf.rose.hp.com>

The following is my current list of issues with the draft that I
posted
in January <draft-flick-repeater-dev-mib-00.txt>.  Assuming that
this is
the draft we use as the basis of our work, I suppose this list
could be
the beginnings of an open-issues list.

As stated with the interfaces MIB issues, this list is not
exhaustive,
and anyone is free to raise issues with this draft.

    1. The biggest issue is alignment with the work of the hubmib
wg on
       the single agent/multiple repeaters issue.

    2. The overview section is currently pretty skimpy.  We need
to add
       text with an overview of our model, structure of the MIB,
       relationship to other MIBs, etc.

    3. vgRptrNonDisruptTest definition is extremely restrictive. 
Is
       there really any selftest that can meet these restrictions
and
       still be useful?  Do we need this object at all?

    4. This MIB models the uplink port as another port in its
per-port
       tables, even though the uplink port is functionally quite
       different from other ports.  This leads to some oddities in
some
       objects in vgRptrBasicPortTable and vgRptrAddrTrackTable.

    5. Should we have a separate Physical Media MIB (or Physical
Media
       table in this MIB) similar to the 802.3 MAU MIB?  In
particular,
       the vgRptrPortMediaType is PMD-dependent.  This MIB doesn't
       model the case of multiple PMDs attached to the same port
very
       well.

    6. There have been some comments about the
vgRptrPortLastTrainConfig
       and vgRptrPortTrainingResult objects.  Some people feel that
they
       should be split up into separate enumerated objects for the
       various fields.  Some others like the ability to atomically
       retrieve this information in a single get.

    7. Some people have requested a few group-wide counters (like
       total octets, total frames, and total errors - similar to
the
       802.3 Repeater MIB).  We need to decide what makes sense
here.

    8. vgRptrMgrDetectedDupAddress is a real kludge.  However, this
is
       the behavior that IEEE defined.  Probably can't change this,
but
       we may want to document its limitations.

    9. The OBJECT-GROUP and MODULE-COMPLIANCE macros in the draft
are
       direct mappings of the IEEE 802.12 "capabilities".  We
probably
       want to change this to something that makes more sense in
an
       SNMP environment.

John