Re: Volunteer for RADIUS MIB documents - MIB Doctor Review

["C. M. Heard" <heard@pobox.com>]

On Sat, 30 Apr 2005, Wijnen, Bert (Bert) wrote:
> A volunteer for these please?
...
> http://www.ietf.org/internet-drafts/draft-nelson-rfc2618bis-00.txt
> http://www.ietf.org/internet-drafts/draft-nelson-rfc2619bis-00.txt
> http://www.ietf.org/internet-drafts/draft-nelson-rfc2620bis-00.txt
> http://www.ietf.org/internet-drafts/draft-nelson-rfc2621bis-00.txt

Unfortunately, I do not have the time to be able to commit to doing
a full MIB Doctor review.  However I did have a brief look at the
documents and I have a serious concern about the approach.

Specifically, each document contains a MIB module that AUGMENTS a
conceptual row entry in an existing table.  The augmenting row
contains IP-version-neutral columns that are intended to replace
some IPv4-specific columns in the augmented row.  There is a
statement in the narrative part of the documents that those
IPv4-specific columns are deprecated -- see Sections 4, 5, and 6 of
the drafts -- but documents do not contain a revised version of the
original MIB module with the status value of the IPv4-specific
objects changed from 'current' to 'deprecated'.

There are two things that bother me about this approach.

First, it is customary when the status of an object in an IETF MIB
module is changed for that MIB module to be reissued with an updated
definition of that object.  The above-mentioned drafts would leave
it up to the user of the MIB module to perform that update.  I don't
think that is wise.  Note that if new revisions of the existing MIB
modules are published, there is little reason not to put the new
objects into the existing tables, rather than making augmenting rows
in new modules.

Second, and more seriously, there is no discussion of what happens
when an agent that implements the new/updated MIB module interacts
with a management application that is built expect the old
definitions.  It is not actually clear to me how to avoid breaking
such applications except by definining an entirely new table (as was
done in draft-ietf-ipv6-rfc2096-update-07.txt, to give one example),
and stipulating in the compliance statements for the new/updated MIB
module that the existing IPv4-specific tables are to be populated
when the address type is IPv4.

If it has already not done so, I would suggest that the RADEXT WG
should explicitly discuss whether or not they want to preserve
backard compatibility with management applications that implement
RFCs 2618 through 2621, since that has a big impact on the design of
the MIB module.

Regards,

Mike Heard