Subject: New Ethernet MIB draft

From: John Flick <[email-masked]>
Date: Wed, 5 Aug 1998 11:23:54 -0700 (PDT)

I am about to submit a new draft of the Ethernet-like MIB to the I-D
editor.  There is a change log in the appendix.  A few remarks about
this draft:

    - I haven't yet removed the ChipSet OIDs, pending resolution of
      what to do with them (hopefully) in Chicago.

    - Compliance section isn't done yet.

    - Haven't finished updating section 3.4 with the IEEE managed
      object to IETF MIB object mappings.

    - I put the new objects relating to MAC Control and PAUSE into a
      new table, the dot3ControlTable.  Is this the way we want this
      structured?  Should MAC Control and PAUSE be separate tables?
      Or should we just keep everything in dot3StatsTable?

    - dot3ControlFunctionsSupported: Is it needed, or is it redundant
      with ifMauAutoNegCapability?  Should it be settable (as in the
      IEEE doc)?  If so, what does it mean to set it?

    - dot3ControlPauseLinkDelayAllowance: Do we need this object?  I
      am a bit unclear as to what it means to set this.  It is not
      mentioned in any of the MAC Control or PAUSE state machines.

    - I did not include counters for aMACControlFramesTransmitted or
      aMACControlFramesReceived, since they should be derivable from
      individual counters for the MAC Control functions.

    - I added dot3ControlPauseMode, which shows what the priority
      resolution for PAUSE resolved to.  I would rather not depend on
      the management app to know how priority resolution works.  Let
      me know if there are objections to this object.

    - I haven't added a DuplexMode object, since the consensus here
      seemed to be that it should be in the IF-MIB.  I believe Brian
      O'Keefe was supposed to be submitting a proposal to the ifmib
      mailing list, but that hasn't happened yet.  If IF-MIB doesn't
      add this object, we should probably add it to this MIB.

    - The proposal I made in L.A. for adding some additional MIB
      objects for PAUSE instrumentation has not received any
      discussion on the mailing list, probably because I haven't
      introduced it.  I still think it is important,  but haven't put
      anything about it in this draft.

Have fun in Chicago,
John