Comments on RADIUS MIB documents - MIB Doctor Review

["Nelson, David" <dnelson@enterasys.com>]

I am forwarding some RADIUS MIB comments to the WG list, with the
author's permission.

I'd like to solicit the WG's opinion on structuring of IPv6 address
support in the RADIUS MIBs, based on the attached comments.

------------------------ Comment 1 -------------------------

> 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

----------------------- Comment 2 ------------------------------

> The specific approach was taken at the request of the WG members.  
> Folks wanted to specifically avoid obsoleting the existing RFCs.  I'd 
> like to get some WG comment on your concerns with that approach.

That sounds fair.  One way to do that -- which I hinted at in my earlier
e-mail -- would be to make new tables to parallel the old, but using
InetAddressType/InetAddress pairs in place of IpAddress (as you did in
the augmentation tables).  The compliance statements for the new MIB
module could then require that both the old table and new table be
instantiated when the address type is IPv4, but not otherwise.  The
downside, obviously, is that there are a lot of extra objects; it is
more efficient for the agent to implement only one set of tables.  The
upside is that management apps that used to work before continue to
work, although they are limited to just the IPv4-related entries, and
the old specs don't have to be revised.

//cmh

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>