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