[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Mib transition
I agree with Juergen that requests for changes in the IEEE 802.1 MIB
modules may happen more often in the future that we want to believe.
However, solution (a) (continue to publish updates to the relevant 802
MIB under IETF control) proved to be unpractical because there is no
longer any consistent constituency in the IETF to do this work, while
solution (b) (the IETF officially transfers the control of the top level
OIDs used by these MIBs over to the IEEE) is not what the IEEE 802.1 WG
wants. The solution to me seems to be in assisting the IEEE 802.1 to
create new MIB extensions at the required quality in their own OID
space, while obsolescing gradually the IETF documents as needed without
further adding anything new.
Regards,
Dan
> -----Original Message-----
> From: owner-mreview@ops.ietf.org
> [mailto:owner-mreview@ops.ietf.org] On Behalf Of Juergen Schoenwaelder
> Sent: Friday, October 07, 2005 9:14 PM
> To: David B Harrington
> Cc: MReview
> Subject: Re: Mib transition
>
> On Fri, Oct 07, 2005 at 01:19:31PM -0400, David B Harrington wrote:
>
> > 2) modifying - SMIv2 doesn't generally permit existing MIB
> objects to
> > be modified. If IEEE wants to change an object not allowed to be
> > changed by SMIv2, they can create a new object under their own arc,
> > and provide a compliance clause that says to use that object rather
> > than the old object.
>
> Not quite true. The SMIv2 actually allows enumerations to be extended.
>
> [...]
>
> > But, I don't see that as being likely. Each of the existing
> documents
> > will be an IETF standard, and because it would have a
> serious impact
> > on interoperability/backwards compatibility, we don't
> generally go in
> > and obsolete large portions of a standard MIB except under unusual
> > circumstances (such as revving RFC1213 or updating existing MIBs for
> > IPv6 support).
>
> Note sure what you mean here - RFC 4188 is a proposed standard now.
>
> > The only case I see where this would be likely is misguided efforts
> > like Alex Ruzin's MSTP-MIB where he wanted to copy existing
> BRIDGE-MIB
> > objects into his MIB, with new OIDs and descriptors under
> the ieee802
> > arc, and obsolete the BRIDGE-MIB objects. This is bad
> practice from a
> > standpoint of interoperability, and if IETF MIB Doctors and
> > knowledgeable 802.1 participants are paying any attention, this is
> > unlikely to happen.
>
> I am less optimistic than you. I do believe that we will see
> valid requests for changes of these MIB modules and we better
> plan ahead for that. Otherwise, people will indeed end up
> copying lots of objects under new OIDs which is a pay for
> interoperability and a clear failure of our process (which
> puts interoperability first). In other words, I believe we
> need to agree that the IETF either (a) continues to publish
> updates to the relevant 802 MIB under IETF control or that
> (b) the IETF officially transfers the control of the toplevel
> OIDs used by these MIBs over to the IEEE.
>
> /js
>
> --
> Juergen Schoenwaelder International University Bremen
> <http://www.eecs.iu-bremen.de/> P.O. Box 750 561,
> 28725 Bremen, Germany
>
>