[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question about draft-ietf-hubmib-rfc3636bis
On Sun, Apr 17, 2005 at 09:20:35PM -0700, C. M. Heard wrote:
> First some background. Historically, each standard MAU type has
> been represented both as an OBJECT IDENTIFIER, which can figure as a
> value for rpMauType, ifMauType, or ifMauDefaultType, and also as a
> bit position in ifMauTypeListBits. These values have been entered
> directly into the MAU-MIB itself as a set of OBJECT-IDENTITY
> definitions and as bit positions in the type for ifMauTypeListBits.
> The WG wants to move these into an IANA-maintained MIB module so
> that it is not necessary to open up the MAU-MIB every time the IEEE
> defines a new 802.3 phyisical layer variant. So far so good, I
> agree with this goal.
Has the option been considered to start an IANA module for all new
assignments and to leave the existing assignments where they are?
Sure, you would loose the freedom to deprecate/obsolete things
via IANA actions but you would side-step the problem perhaps.
> There is, however, a potential backward compatibility issue in
> moving the existing OBJECT-IDENTITY definitions out of the MAU-MIB,
> namely that it would break any MIB modules that happened to import
> those definitions from the MAU-MIB. I suggested to the author to
> turn the existing definitions as OBJECT IDENTIFIER assignments (as
> permitted by RFC 2578 Section 3.6) so that they could continue to be
> imported from the MAU-MIB. That suggestion has, however, met with
> some resistance: it causes lots of smilint warnings, assuming that
> default settings are used, and no one has been able to find any
> example of a MIB module that imports one of the definitions in
> question (for sure no IETF standard MIB module does so).
>
> What would you other MIB Doctors advise in this case?
I believe that this decision at the end belongs to the WG. I think it
is important that the implications are brought to their attention and
that the WG takes responsibility of the consequences. Furthermore, if
the WG finally decides to move things, I think it is important that
the updated document has clear instructions in the module that tell
people where definitions have moved to.
/js (who is in his "be flexible" mood today)
--
Juergen Schoenwaelder International University Bremen
<http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany