Subject: MIB review comments

From: John Flick <[email-masked]>
Date: Tue, 11 May 1999 18:32:05 -0700 (PDT)

Hi,

The reviewer appointed by our ADs has completed his review of our
documents, and I am just finishing the updates to reflect the results
of that review.  In addition, I received the following
comments/questions in private e-mail, that we should probably address:

  - Counters should indicate what to use as a discontinuity
    indicator.

    I believe that this is either a sysUpTime reset, or a change in
    ifCounterDiscontinuityTime for all Ethernet or ifMau MIB counters.
    for rpMau MIB counters, this is either a sysUpTime reset or a
    change in rptrMonitorPortLastChange.

  - The entries in the table in section 3.5 for aFramesTransmittedOK
    and aFramesReceivedOK are not correct, since the IEEE document
    counts successful transmits/receives, whereas the IF-MIB counts
    packets sent to/from a higher layer.

  - Which counters should/should not count PAUSE frames (or, more
    generally, MAC Control frames)?  They are generated/consumed
    within a sublayer of the ethernet interface layer, not sent
    to/from a higher layer.

I have listed the edits to the document that I believe address all of
the review comments and the above additional comments.  Please review
these changes.  I would like to submit this document to the I-D editor
on Friday, May 14.

Thanks,
John

Ethernet MIB Review Changes:

- Update SNMP Management Framework boilerplate and references to refer
  to new SMI documents.  Also, Bert advised that we update the references
  for the new SNMPv3 documents while we're at it.  (They haven't been
  officially released, but he told us what the numbers will be.)

- Add "Guidelines" header to second column of table in section 3.2.7.

- Updated the following entries in the table in section 3.2.7:

  ifInOctets                 The number of octets in valid MAC frames
                             received on this interface, including
                             the MAC header and FCS.  This does
                             include the number of octets in valid
                             MAC Control frames received on this
                             interface.

  ifInUcastPkts              Refer to [25].  Note that this does not
                             include MAC Control frames, since MAC
                             Control frames are consumed by the
                             interface layer and are not passed to
                             any higher layer protocol.

  ifOutOctets                The number of octets transmitted in
                             valid MAC frames on this interface,
                             including the MAC header and FCS.  This
                             does include the number of octets in
                             valid MAC Control frames transmitted on
                             this interface.

  ifOutUcastPkts             Refer to [25].  Note that this does not
                             include MAC Control frames, since MAC
                             Control frames are generated by the
                             interface layer, and are not passed from
                             any higher layer protocol.

  ifInMulticastPkts          Refer to [25].  Note that this does not
                             include MAC Control frames, since MAC
                             Control frames are consumed by the
                             interface layer and are not passed to
                             any higher layer protocol.

  ifInBroadcastPkts          Refer to [25].  Note that this does not
                             include MAC Control frames, since MAC
                             Control frames are generated by the
                             interface layer, and are not passed from
                             any higher layer protocol.

  ifOutMulticastPkts         Refer to [25].  Note that this does not
                             include MAC Control frames, since MAC
                             Control frames are consumed by the
                             interface layer and are not passed to
                             any higher layer protocol.

  ifOutBroadcastPkts         Refer to [25].  Note that this does not
                             include MAC Control frames, since MAC
                             Control frames are generated by the
                             interface layer, and are not passed from
                             any higher layer protocol.

  ifCounterDiscontinuityTime Refer to [25].  Note that a
                             discontinuity in the Interface MIB
                             counters may also indicate a
                             discontinuity in some or all of the
                             counters in this MIB that are associated
                             with that interface.

- Added the following text to section 3.5, immediately following the
  formulas for deriving IF-MIB octet counters from IEEE 802.3
  instrumentation:

    Also note that the packet counters in the IF-MIB do not exactly match
    the definition of the frame counters in IEEE 802.3.
    aFramesTransmittedOK counts the number of frames successfully
    transmitted on the interface, whereas ifOutUcastPkts,
    ifOutMulticastPkts and ifOutBroadcastPkts count the number of
    transmit requests made from a higher layer, whether or not the
    transmit attempt was successful.  This means that packets counted by
    ifOutErrors or ifOutDiscards are also be counted by ifOut*castPkts,
    but are not be counted by aFramesTransmittedOK.  This also means
    that, since MAC Control frames are generated by a sublayer internal
    to the interface layer rather than by a higher layer, they are not
    counted by ifOut*castPkts, but are counted by aFramesTransmittedOK.

    Similarly, aFramesReceivedOK counts the number of frames received
    successfully by the interface, whether or not they are passed to a
    higher layer, whereas ifInUcastPkts, ifInMulticastPkts and
    ifInBroadcastPkts count only the number of packets passed to a higher
    layer.  This means that packets counted by ifInDiscards or
    ifInUnknownProtos are also counted by aFramesReceivedOK, but are not
    counted by ifIn*castPkts.  This also menas that, since MAC Control
    frames are consumed by a sublayer internal to the interface layer and
    not passed to a higher layer, they are not counted by ifIn*castPkts,
    but are counted by aFramesReceivedOK.

    Another difference to keep in mind between the IF-MIB counters and
    IEEE 802.3 counters is that in the IEEE 802.3 document, the frame
    counters and octet counters are always incremented together.
    aOctetsTransmittedOK counts the number of octets in frames that were
    counted by aFramesTransmittedOK.  aOctetsReceivedOK counts the number
    of octets in frames that were counted by aFramesReceivedOK.  This is
    not the case with the IF-MIB counters.  The IF-MIB octet counters
    count the number of octets sent to or received from the layer below
    this interface, whereas the packet counters count the number of
    packets sent to or received from the layer above.  Therefore,
    received MAC Control frames, ifInDiscards, and ifInUnknownProtos are
    counted by ifInOctets, but not ifIn*castPkts.  Transmitted MAC
    Control frames are counted by ifOutOctets, but not ifOut*castPkts.
    ifOutDiscards and ifOutErrors are counted by ifOut*castPkts, but
    not ifOutOctets.

- Remove Unsigned32 from the IMPORTS statement

- Update LAST-UPDATED clause in MODULE-IDENTITY macro

- Added the following text to the DESCRIPTION of dot3StatsTable:

            There will be one row in this table for each
            ethernet-like interface in the system.

- Added the following text to the DESCRIPTIONs of all Counter32s:

            Discontinuities in the value of this counter can
            occur at re-initialization of the management
            system, and at other times as indicated by the
            value of ifCounterDiscontinuityTime.

- Added the following text to the DESCRIPTION of dot3StatsDuplexStatus:

            Note that this object provides redundant
            information with ifMauType.  Normally, redundant
            objects are discouraged.  However, in this
            instance, it allows a management application to
            determine the duplex status of an interface
            without having to know every possible value of
            ifMauType.  This was felt to be sufficiently
            valuable to justify the redundancy.

- Added the following text to the DESCRIPTION of dot3ControlTable:

                                There will be one row in
            this table for each ethernet-like interface in
            the system which implements the MAC Control
            sublayer.  If some, but not all, of the
            ethernet-like interfaces in the system implement
            the MAC Control sublayer, there will be fewer
            rows in this table than in the dot3StatsTable.

- Changed the SYNTAX clause of dot3ControlFunctionsSupported from:
            SYNTAX      BITS {
                            pause(0)
                        }
to:
            SYNTAX      BITS {
                            pause(0)   -- 802.3x flow control
                        }

- Added the following text to the DESCRIPTION of dot3PauseTable:

                               There will be one row in
            this table for each ethernet-like interface in
            the system which supports the MAC Control PAUSE
            function (i.e., the 'pause' bit in the
            corresponding instance of
            dot3ControlFunctionsSupported is set).  If some,
            but not all, of the ethernet-like interfaces in
            the system implement the MAC Control PAUSE
            function (for example, if some interfaces only
            support half-duplex), there will be fewer rows
            in this table than in the dot3StatsTable.

- Added the following comment after dot3Errors:

       -- { dot3 8 }, the dot3ChipSets tree, is defined in [28]

MAU MIB Review Changes:

- Update SNMP Management Framework boilerplate and references.

- Update LAST-UPDATED clause in MODULE-IDENTITY macro

- Added the following text to the DESCRIPTION of dot3MauType10BaseT:

            Note that it is strongly recommended that
            agents return either dot3MauType10BaseTHD or
            dot3MauType10BaseTFD if the duplex mode is
            known.  However, management applications should
            be prepared to receive this MAU type value from
            older agent implementations.

- Added the following text to the DESCRIPTION of dot3MauType10BaseFL:

            Note that it is strongly recommended that
            agents return either dot3MauType10BaseFLHD or
            dot3MauType10BaseFLFD if the duplex mode is
            known.  However, management applications should
            be prepared to receive this MAU type value from
            older agent implementations.

- Made the following changes to the DESCRIPTION of rpMauMediaAvailable:

     - Changed:
            The value other(1) is returned if the
            mediaAvailable state is not one of 2 through 6.
       to:
            The value other(1) is returned if the
            mediaAvailable state is not one of 2 through 11.

      - Changed:
            For 100Mbps and 1000Mbps MAUs, the enumerations
            match the states within the respective link
            integrity state diagrams, fig 32-16, 23-12 and
            24-15 of sections 32, 23 and 24 of [2].
        to:
            For 100Mbps and 1000Mbps MAUs, the enumerations
            match the states within the respective link
            integrity state diagrams, fig 32-16, 23-12 and
            24-15 of sections 32, 23 and 24 of [16].

- Added the following text to the DESCRIPTIONs of
  rpMauMediaAvailableStateExits, rpMauJabberingStateEnters, and
  rpMauFalseCarriers:

            Discontinuities in the value of this counter can
            occur at re-initialization of the management
            system, and at other times as indicated by the
            value of rptrMonitorPortLastChange.

- In the DESCRIPTION of ifMauType, changed:
            This object identifies the 10 or 100 Mb/s
            baseband or broadband MAU type.
  to:
            This object identifies the MAU type.

- Made the following changes to the DESCRIPTION of ifMauMediaAvailable:

     - Changed:
            The value other(1) is returned if the
            mediaAvailable state is not one of 2 through 6.
       to:
            The value other(1) is returned if the
            mediaAvailable state is not one of 2 through 11.

      - Changed:
            For 100Mbps and 1000Mbps MAUs, the enumerations
            match the states within the respective link
            integrity state diagrams, fig 32-16, 23-12 and
            24-15 of sections 32, 23 and 24 of [2].
        to:
            For 100Mbps and 1000Mbps MAUs, the enumerations
            match the states within the respective link
            integrity state diagrams, fig 32-16, 23-12 and
            24-15 of sections 32, 23 and 24 of [16].

- Added the following text to the DESCRIPTIONs of
  ifMauMediaAvailableStateExits, ifMauJabberingStateEnters, and
  ifMauFalseCarriers:

            Discontinuities in the value of this counter can
            occur at re-initialization of the management
            system, and at other times as indicated by the
            value of ifCounterDiscontinuityTime.

- Added the following text to the DESCRIPTION of ifMauTypeListBits:

            Note that this MAU may be capable of operating
            as a MAU type that is beyond the scope of this
            MIB.  This is indicated by returning the
            bit value bOther in addition to any bit values
            for capabilities that are listed above.

- Added the following text to the DESCRIPTION of
  ifMauAutoNegCapabilityBits:

            Note that the local auto-negotiation entity may
            support some capabilities beyond the scope of
            this MIB.  This is indicated by returning the
            bit value bOther in addition to any bit values
            for capabilities that are listed above.

- In the description of ifMauAutoNegCapAdvertisedBits, changed:
            Capabilities in this object that are not
            available in ifMauAutoNegCapability cannot be
            enabled.
  to:
            Capabilities in this object that are not
            available in ifMauAutoNegCapabilityBits cannot
            be enabled.

- Added the following text to the DESCRIPTION of
  ifMauAutoNegCapAdvertisedBits:

            Note that the local auto-negotiation entity may
            advertise some capabilities beyond the scope of
            this MIB.  This is indicated by returning the
            bit value bOther in addition to any bit values
            for capabilities that are listed above.

- In the DESCRIPTION of ifMauAutoNegCapReceivedBits, changed:

            Note that interfaces that support this MIB may
            be attached to remote auto-negotiation entities
            which have capabilities beyond the scope of this
            MIB.
  to:
            Note that interfaces that support this MIB may
            be attached to remote auto-negotiation entities
            which have capabilities beyond the scope of this
            MIB.  This is indicated by returning the bit
            value bOther in addition to any bit values for
            capabilities that are listed above.

Chipset MIB Review Changes:

- Update SNMP Management Framework boilerplate and references.