Comments on RADIUS MIB documents - MIB Doctor Review
"Nelson, David" <dnelson@enterasys.com> Mon, 02 May 2005 17:23 UTC
Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 02 May 2005 17:24:54 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: Comments on RADIUS MIB documents - MIB Doctor Review
Date: Mon, 02 May 2005 13:23:55 -0400
Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D690103230D@MAANDMBX2.ets.enterasys.com>
Thread-Topic: Comments on RADIUS MIB documents - MIB Doctor Review
Thread-Index: AcVOxX0bPVyT41DrT7ynBJfBc3gmLQAdWDYg
From: "Nelson, David" <dnelson@enterasys.com>
To: radiusext@ops.ietf.org
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/>
- Re: Comments on RADIUS MIB documents - MIB Doctor… Alan DeKok
- RE: Comments on RADIUS MIB documents - MIB Doctor… Nelson, David
- RE: Comments on RADIUS MIB documents - MIB Doctor… Romascanu, Dan (Dan)
- RE: Comments on RADIUS MIB documents - MIB Doctor… Nelson, David
- RE: Comments on RADIUS MIB documents - MIB Doctor… Romascanu, Dan (Dan)
- Comments on RADIUS MIB documents - MIB Doctor Rev… Nelson, David