[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on RADIUS MIB documents - MIB Doctor Review
I believe that we need to redefine the tables in the new MIB modules in any case.
- if backwards compatibility with existing management applications is required this can be achieved only by defining new tables, as demonstrated by Bert
- if backwards compatibility is not required, why bother AUGMENT-ing? The AUGMENTS would not work because there can be no one-to-one relationship with the rows pointing to ipv6 objects.
IMHO the 'clean way' is to deprecate 2618 to 2621, replace the address objects with the new TCs, and place all under new root OIDs.
Are there many IPv4 only implementations out there that would need to be replaced in deployment?
Regards,
Dan
> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org]On Behalf Of Nelson, David
> Sent: 02 May, 2005 8:24 PM
> To: radiusext@ops.ietf.org
> Subject: Comments on RADIUS MIB documents - MIB Doctor Review
>
>
> 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/>
>
--
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/>