Subject: MAU MIB open issues

From: John Flick <[email-masked]>
Date: Fri, 30 Oct 1998 17:08:14 -0800 (PST)

I am trying to put together an updated draft for the MAU MIB.  The
goal is to make this our WG last call draft.  The following are
changes we must make (based on IESG feedback when going through the
Ether-like MIB approval process):

   - update the framework boilerplate to the version on the O&M web
     page
   - move the Change Log section to an appendix
   - update the Security Considerations section to the latest approved 
     incantation

There are still a few outstanding issues:

1. Forward reference problem with snmpDot3MauMgt
   I think this is one we just need to live with, since we haven't
   been able to come up with a fix that will work with all MIB
   compilers and still be legal according to RFC1902.

2. Are the DESCRIPTION clauses for ifMauAutoNegRemoteFaultAdvertised
   and ifMauAutoNegRemoteFaultReceived consistent and correct?  Could
   they be made clearer?
   I am open to suggestions here.

3. JackType TC needs to be updated with new jack types.
   I believe Andrew is working on this one.

4. Should we worry now about what to deprecate as a result of
   implementor feedback, or wait until we actually have a chance to
   advance to Draft?
   I am assuming that with the changes we are making in adding several 
   new objects and replacing the bits-like INTEGER objects with actual
   BITS objects that we probably won't be able to advance directly to
   Draft.  We could put this off, and do another implementor's survey
   when we actually have a chance of advancing.  Or we could deprecate 
   some things now that we know are never going to get implemented
   (like broadMauBasicTable) and worry about some questionable ones
   (rpJackTable, rpMauFalseCarriers) in the next go-round.

5. Should some of the MAX-ACCESS read-write objects have a MIN-ACCESS
   of read-only in the MODULE-COMPLIANCE statements?
   The following objects have MAX-ACCESS read-write:
       rpMauStatus
       ifMauStatus
       ifMauDefaultType
       ifMauAutoNegAdminStatus
       ifMauAutoNegRestart
       ifMauAutoNegCapAdvertisedBits
       ifMauAutoNegRemoteFaultAdvertised
   Implementor feedback seemed to implement many, if not all, of these 
   objects were implemented read-only on some implementations.  Which
   should it be considered compliant behaviour to implement read-only?

Feedback on these issues would be GREATLY appreciated.  If not, the
chair and editors will just have to decide for you :-)

Thanks,
John

---

From: Andrew Smith <[email-masked]>
Date: Fri, 30 Oct 1998 17:26:58 -0800

I'd propose 2 new Jack Types:

                      mtrj(12),   -- fibre MT-RJ
                      hssdc(13)   -- fibre channel style-2

For 100base-FX the new connector is called "MT-RJ" (can't find a technical
reference). There are also plans afoot to use this for gigabit.

For 1000base-CX, one of the styles of connector is called "8-pin shielded
ANSI Fibre channel Style-2 connector with mechanical mating interface
defined by IEC 61076-3-103". Phew. I am reliably informed that it is
popularly known as "HSSDC". Reference IEEE 802.3z 39.5.1.2.

For 1000base-T there is no need for any new connector - rj45s(3) is the
correct jack type to return here.

Andrew

> -----Original Message-----
> From: John Flick [mailto:[email-masked]]
> Sent: Friday, October 30, 1998 5:08 PM
> To: [email-masked]
> Subject: MAU MIB open issues

>    I believe Andrew is working on this one.

****************************************************************
Andrew Smith                              tel: +1 (408) 863-2821
Extreme Networks                          fax: +1 (408) 342-0990
10460 Bandley Drive               http://www.extremenetworks.com
Cupertino CA 95014               em:  [email-masked]
****************************************************************