Re: rfc3636bis-02

"C. M. Heard" <[email protected]> Mon, 24 Oct 2005 06:57:51 -0700 (PDT)
Newsgroups gmane.ietf.hubmib
Message-ID <[email protected]>
On Mon, 24 Oct 2005, Edward Beili wrote:
> I've submitted the 02 version of rfc3636bis (MAU-MIB). It will
> probably take a day or two for the official IETF announcement,
> so I've attached it for your convenience.
> 
> Most changes were done according to your comments, see below.

Thanks, I'll look it over and provide comments as soon as I am able.

> I'd like to ask your advice on 2 issues:
> 
> 1. Currently the values for the ifMauTypeListBits are defined in the
>    IANA-MAU-MIB, while the values for the ifMauAutoNegCapabilityBits,
>    ifMauAutoNegCapAdvertisedBits and ifMauAutoNegCapReceivedBits objects
>    are defined in MAU-MIB.
>    While none of the newly added MAU types (10GBASE-CX4, 2BASE-TL,
>    10PASS-TS, 100BASE-LX/BX, 1000BASE-LX/BX/PX) supports
>    auto-negotiation, this may change in the future (e.g. I don't see
>    a reason not to support it on P2P (-LX/BX) optical links as well as
>    for some new types). I suggest to put TC for these objects in the
>    IANA-MAU-MIB as well.

The WG of course has the last word but this suggestion does seem logical
to me.  Since the SYNTAX clauses for the three above-mentioned objects
are identical, a single new IANA-maintained TC would suffice.

> 2. I left ianaMauMIB and dot3MauType location as it was in v01,
>    adding the relevant ASN comments in the MIB.
>    I do agree however with your past argument about moving
>    ianaMauMIB under mib-2 (and subsequently dot3MauType under
>    ianaMauMIB). If the working group agrees I would do the
>    change in the next draft.

I can live with it the way it is, now that we have the ASN.1 comments
to help prevent duplicate assignments, but I would still prefer to
see it moved.  But as you say the WG has the last word.

Thanks again for getting this version posted.

Mike