aa11647;
          31 May 95 22:09 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id
aa11643;
          31 May 95 22:09 EDT
Received: from hp.com by CNRI.Reston.VA.US id aa21548; 31 May 95
22:09 EDT
Received: from hprnd.rose.hp.com by hp.com with ESMTP
     (1.37.109.15/15.5+ECS 3.3) id AA273112565; Wed, 31 May 1995
19:09:25 -0700
Received: from hprnljf.rose.hp.com by hprnd.rose.hp.com with SMTP
     (1.37.109.14/15.5+ECS 3.3) id AA059312560; Wed, 31 May 1995
19:09:20 -0700
Message-Id: <199506010209.AA059312560@hprnd.rose.hp.com>
Received: from localhost by hprnljf.rose.hp.com with SMTP
     (1.38.193.4/16.2) id AA04349; Wed, 31 May 1995 19:14:03 -0700
To: vgmib@hprnd.rose.hp.com
Subject: VG Interface MIB issues
Date: Wed, 31 May 1995 19:14:03 -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-interfaces-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.

This list is just the issues that I know about.  Obviously others
are
free to raise issues with this draft.  It is up to the WG chair to
decide how he wants to structure this discussion, but I would
suggest that responses to individual issues be separated into
separate
posts to the make the discussion easier to track.  We should
probably
try to resolve at least some of these issues before the end of
June,
when we are scheduled to produce our first official
internet-drafts.

    1. Might be helpful to add a section which details how RFC 1573
       objects are applied to VG interfaces.

    2. Add text stating that agents with VG interfaces operating
in
       token ring framing mode that support source routing should
       implement the Station Source Routing MIB (RFC 1749).

    3. Need to clarify the relationship of ifPromiscuousMode to
       dot12DesiredPromiscStatus.

    4. Should probably add text clarifying why there are counters
for
       received normal priority frames and octets, but not for
       transmitted normal proirity frames and octets.

    5. Should we define test types for VG interfaces for use with
       ifTestTable?

    6. There are no counters in the dot12StatTable reflecting
transmit
       errors.  Are there truly no errors that can occur on
transmit?

    7. Should we have some sort of internalTransmitErrors and
       internalReceiveErrors (similar to ethernet MIB) for things
like
       overrun/underrun, etc.?

    8. Do we really need dot12InNullAddressedFrames?  It is only
       meaningful when the interface is in promiscuous mode, since
it
       won't see these frames otherwise.

    9. Question from Danvers BOF: Should dot12Status also have a
       'closing' state indicating that a 'close' command has been
issued
       but the interface has not yet been disabled?  If so, there
is a
       problem of consistency with the Token Ring MIB (RFC 1748).

   10. Should there be a separate Physical Media MIB (similar to
the
       802.3 MAU MIB)?  If so, dot12MediaType probably belongs in
that
       MIB rather than in this one.  Having mediaType in the
interface
       MIB doesn't work well if you have multiple PMDs attached to
the
       same interface (e.g. for backup).

   11. The OBJECT-GROUP and MODULE-COMPLIANCE statements currently
       correspond to the "capabilities" defined in the IEEE
document.
       We probably want to define compliance statements that make
more
       sense for an SNMP environment.

   12. I have received some comments from people who don't like the
       dot12LastTrainingConfig bitmask, and would prefer splitting
it
       up into separate, enumerated integer objects.  Others want
to
       keep it as is, since it is a direct snapshot of the field
       returned in the training packets that concisely conveys
exactly
       what happened during the last training attempt.  What does
the
       working group want to do here?

John