[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Where to root MIB modules
HI,
Your message below is a good summary of the situation.
It leads to two questions, which are:
1) Is the trend for errors in assigments by IANA getting
better, worse, or staying the same. Or another way,
has IANA made any mistakes in the last couple of years
and do they have a process in place to "eliminate"
mistakes?
2) Why is there is need for changing MIB descriptors?
(My answer - inadequate tools!)
Changing OIDs and descriptors is an error prone
process and can result in management apps (and possibly
agents) supporting 2 (or more) copies of object,
notificaton, and TC definitions.
What if there was a programmatic way to rename
descriptors. For example, to prefix each lowercase
descriptor with xn and uppercase descriptor with Xn.
For example, descriptor "myObject" would be renamed
to "x1myObject" in prerelease 1 of the MIB module.
In summary - work out some scenarios to see the
consequence of each policy.
An observation - there are forces that cause actions.
For IEEE and IETF technical specifications, users are
concerned about interoperability between products
from different vendors. Also, product reviews and
formal test groups focus on interoperability. In
general, if there is no interoperability the
"system will not work". There is no work around
in using a feature/capability where there is
no interoperability other than a single vendor
solution. However, for management, the current
state is that proprietary solutions are needed for
configuration (with a few exceptions), and for
monitoring, it is accepted that an "adapter layer"
will be used to modify retrieved data so that
it fits the model used by the management station.
So, bottom line is that I don't see the pressures
to force the implemenation of management interfaces
(MIB definitions) to move from a pre-release to
a final version of a technical specification,
as long as the pre-release specification
is good enough.
Regards,
/david t. perkins
On Mon, 5 Jan 2004, Harrington, David wrote:
> Hi Mike,
>
> Part 1: the rmon experience
>
> I reviewed the document you mentioned. It discusses turning over the
> authority for rmon assignment to IANA, and how to handle existing
> assignments. It doesn't discuss at length any problems of
> interoperability that were caused by the earlier approach, except that
> sometimes people made mistakes and reused assignments, and some
> assignments ended up being obsolete. IANA has made a few mistakes as
> well, and some asssignments become obsolete, so I didn't see using IANA
> as a better solution, merely a different solution. I agree that since
> IANA's job is to assign numbers, it seems beneficial to coordinate the
> assignments through IANA, but the WG could add text to a document that
> when approved as an RFC, IANA should add the assignments to the existing
> list, as is done in this rmon-oids document, as has been proposed for
> RADIUS attribute IDs, and many other working-group-maintained but
> IANA-blessed assignments.
>
> Part 2: the problem with IANA assignments at RFC time
>
> There have been IETF discussions in the past about documents that were
> "good enough" versus documents that were "perfect".
>
> I have concerns that not assigning an OID until a mib is published as an
> RFC is sub-optimal for reality. In an era when time-to-market is a
> constant vendor concern, and the 24 months it takes to approve Proposed
> Standard documents has been identified as an IETF problem to be
> addressed, forcing this additional delay in the availability of a mib
> via the IANA assignment of OIDs at RFC time seems counterproductive.
>
> The IETF and other SDOs, such as IEEE, produce working drafts of
> protocols which are commonly implemented in pre-standard implementations
> and released as products. While there is often a period of potential
> non-interoperability in pre-standard releases, the vendors and customers
> seem to weather this well, and change to the ratified-standard as soon
> as it is available.
>
> This cannot be done easily with IETF mibs because the OID assignment is
> held off until the specification is published as an RFC. We wait for
> "perfection" before assigning an OID. Vendors who want to release a
> pre-standard implementation are forced to cut-and-paste the mib, and
> change the descriptors and OID assignments. Once they have provided the
> functionality in a proprietary mib and a corresponding application that
> understands their proprietary OIDs, there is little motivation for
> vendors to migrate to the IETF standard descriptors and OIDs to provide
> the same functionality.
>
> The operator community has complained that the availability of standard
> mibs is way too slow, often coming years after the availability of the
> protocol which the mib tries to make manageable. This is becoming more
> apparent now that other SDO working groups, like IEEE 802.1 and 802.3
> and 802.11, have adopted SNMP mibs as their management approach.
>
> We have a way to improve the speed of availability of mibs - let the
> assignment of OIDs happen while the mib is under development in
> internet-drafts and before being published as an RFC. This will allow
> vendors to release products with pre-standard implementations of the mib
> that can be corrected when the mib is ratified, much as they do with the
> managed protocols.
>
> Waiting until the mib is published as an RFC to assign an OID causes an
> **unnecessary** delay that is often not found in other industry
> standards.
>
> Part 3: OID assignments and the DHCP mib
>
> The DHCP server mib uses a dhcp { mib-2 TBD } IANA assignment, and then
> "pre-assigns" certain OIDs for anticipated mib module extensions within
> that subtree such as { dhcp 2 } for a dhcp client mib and { dhcp 3 } for
> a dhcpv4 relay, and { dhcp 4 } for a dhcpv6 server mib. [these are
> commented out, but still exist in the document.]
>
> Is this "pre-assignment" considered bad practice? As a mib doctor should
> I ask that such pre-assignment comments be removed from the mib? Should
> these extensions all be at the { mib-2 xxx } level?
>
> dbh
>
> > -----Original Message-----
> > From: C. M. Heard [mailto:heard@pobox.com]
> > Sent: Monday, January 05, 2004 10:30 AM
> > To: Mreview (E-mail)
> > Subject: RE: Where to root MIB modules
> >
> >
> > On Mon, 5 Jan 2004, Harrington, David wrote:
> > > I think allowing a wg to assign the oids for their mibs, in a
> > > controlled manner, might be a good thing to consider.
> >
> > The RMONMIB WG used to do exactly that, but recently turned over the
> > job to IANA. See draft-ietf-rmonmib-rmon-oid-assignments-01.txt.
> >
> > //cmh
> >
> >
> >
>