RE: Volunteer for RADIUS MIB documents - MIB Doctor Review

["David B Harrington" <ietfdbh@comcast.net>]

Hi,

I have not volunteered to review the documents because I provided
advice regarding their design.

I think it important to understand that I recommended the AUGMENTS
approach (if there is a one-to-one correspondence in the rows). I'll
forward my recommendations/comments in a separate email.

I'm open to recommendations for different approaches and corrections
to my analysis.

David Harrington
dbharrington@comcast.net
 
> -----Original Message-----
> From: owner-mreview@ops.ietf.org 
> [mailto:owner-mreview@ops.ietf.org] On Behalf Of C. M. Heard
> Sent: Sunday, May 01, 2005 11:16 PM
> To: Mreview (E-mail)
> Cc: David B. Nelson; Bernard Aboba
> Subject: Re: Volunteer for RADIUS MIB documents - MIB Doctor Review
> 
> 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
> 
> 
>