RE: radius dynauth client/server mibs structure

"Nelson, David" <dnelson@enterasys.com> Fri, 03 March 2006 15:44 UTC

Envelope-to: radiusext-data@psg.com
Delivery-date: Fri, 03 Mar 2006 15:44:47 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: radius dynauth client/server mibs structure
Date: Fri, 03 Mar 2006 10:44:41 -0500
Message-ID: <3CFB564E055A594B82C4FE89D21565602190D1@MABOSEVS2.ets.enterasys.com>
Thread-Topic: radius dynauth client/server mibs structure
thread-index: AcY+0DSXD0oR9cZ8SgKNK7KO8pTe3AACKYzg
From: "Nelson, David" <dnelson@enterasys.com>
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, "Nagi Reddy Jonnala (njonnala)" <njonnala@cisco.com>, j.schoenwaelder@iu-bremen.de, radiusext@ops.ietf.org

Bert Wijnen writes...

> The disadvantage of not doing so is in the future when adding scalars
> and thing not having grouped as nicely and so more complexity.

In practice, does this inconvenient grouping really affect any SNMP
applications in a user-visible way, except for MIB-walk and MIB-browser
applications?

> This is not a blocking comment, just another MIB-type person believing
> that the change would be real EASY now, and it will certainly make
> things cleaner/easier in the future.

It certainly makes the MIB _document_ neater.


--
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/>