RE: radius dynauth client/server mibs structure
"Nagi Reddy Jonnala \(njonnala\)" <njonnala@cisco.com> Tue, 14 February 2006 10:23 UTC
Envelope-to: radiusext-data@psg.com
Delivery-date: Tue, 14 Feb 2006 10:25:08 +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: Tue, 14 Feb 2006 15:53:54 +0530
Message-ID: <61D6551D82BC7149967B39B5C66879F8CDDCA1@xmb-blr-416.apac.cisco.com>
Thread-Topic: radius dynauth client/server mibs structure
Thread-Index: AcYs3htqnVXg8ntFSbCV9v4LkLgAeAEcETVg
From: "Nagi Reddy Jonnala (njonnala)" <njonnala@cisco.com>
To: j.schoenwaelder@iu-bremen.de, radiusext@ops.ietf.org
Cc: Bert Wijnen <bwijnen@lucent.com>
Juergen, Your comments may be correct. We authors have discussed about your comments and realized that the comments are not directly related to these MIBs but in general whether the scalars should be grouped together or not. The recommended way can best be addressed in the IETF MIB guidelines. Since there seem to be plenty of MIBs that don't follow your commented approach, no recommended way in the IETF MIB guidelines and because it is a stylistic change, we leave the MIBs as they are. Thanks Nagi. -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Thursday, February 09, 2006 12:03 AM To: radiusext@ops.ietf.org Cc: Bert Wijnen Subject: radius dynauth client/server mibs structure Hi, I took a quick look at the radius dynauth client/server mibs today: draft-ietf-radext-dynauth-client-mib-03.txt draft-ietf-radext-dynauth-server-mib-03.txt While looking at the OID tree, I came up with the following stylistic change. Currently, the OID tree of the two MIBs basically looks like this (details of the tables and conformance nodes deleted): --radiusDynAuthServerMIB(1.3.6.1.2.1.xxx) | +--radiusDynAuthServerMIBObjects(1) | | | +--radiusDynAuthServer(1) | | | +--radiusDynAuthServerDisconInvalidClientAddresses(1) | +--radiusDynAuthServerCoAInvalidClientAddresses(2) | +--radiusDynAuthServerIdentifier(3) | | | +--radiusDynAuthClientTable(4) | +--radiusDynAuthServerMIBConformance(2) --radiusDynAuthClientMIB(1.3.6.1.2.1.yyy) | +--radiusDynAuthClientMIBObjects(1) | | | +--radiusDynAuthClient(1) | | | +--radiusDynAuthClientDisconInvalidServerAddresses(1) | +--radiusDynAuthClientCoAInvalidServerAddresses(2) | | | +--radiusDynAuthServerTable(3) | +--radiusDynAuthClientMIBConformance(2) I was wondering what the value of having the radiusDynAuthServer and radiusDynAuthClient nodes is. I do understand if people like to group related scalars together (so additions are numbered using consecutive identifiers), but then the OID structure should more look like the following: --radiusDynAuthServerMIB(1.3.6.1.2.1.xxx) | +--radiusDynAuthServerMIBObjects(1) | | | +--radiusDynAuthServerScalars(1) | | | | | +--radiusDynAuthServerDisconInvalidClientAddresses(1) | | +--radiusDynAuthServerCoAInvalidClientAddresses(2) | | +--radiusDynAuthServerIdentifier(3) | | | +--radiusDynAuthClientTable(2) | +--radiusDynAuthServerMIBConformance(2) --radiusDynAuthClientMIB(1.3.6.1.2.1.yyy) | +--radiusDynAuthClientMIBObjects(1) | | | +--radiusDynAuthClientScalars(1) | | | | | +--radiusDynAuthClientDisconInvalidServerAddresses(1) | | +--radiusDynAuthClientCoAInvalidServerAddresses(2) | | | +--radiusDynAuthServerTable(2) | +--radiusDynAuthClientMIBConformance(2) The benefit of this change is that you can add scalars later while keep all the scalars rooted together and consecutively numbered while in the current scheme you end up to have tables intermixed with scalars over time. Please note that there is nothing technically wrong with the MIBs as they are right now. My suggestion is purely stylistic and basically just increases readability in case updates are done in the future. I am aware that these MIB modules have passed WG last call and MIB review and are in the hands of the ADs and as such I do not ask to make a change just for stylistic reasons. I just wanted to bring this to your attention and I like to leave it to the editors/chairs to decide whether you want to make the relatively simple changes at this point in time or prefer to go ahead with what you have. /js -- Juergen Schoenwaelder International University Bremen <http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany -- 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/>
- RE: radius dynauth client/server mibs structure Nagi Reddy Jonnala (njonnala)
- radius dynauth client/server mibs structure Juergen Schoenwaelder
- RE: radius dynauth client/server mibs structure Wijnen, Bert (Bert)
- Re: radius dynauth client/server mibs structure Juergen Schoenwaelder
- RE: radius dynauth client/server mibs structure Nagi Reddy Jonnala (njonnala)
- Re: radius dynauth client/server mibs structure Juergen Schoenwaelder
- Re: radius dynauth client/server mibs structure stefaan.de_cnodder
- Re: radius dynauth client/server mibs structure stefaan.de_cnodder
- RE: radius dynauth client/server mibs structure Nelson, David
- Re: radius dynauth client/server mibs structure stefaan.de_cnodder
- RE: radius dynauth client/server mibs structure Nelson, David
- RE: radius dynauth client/server mibs structure Wijnen, Bert (Bert)
- RE: radius dynauth client/server mibs structure Nelson, David
- Re: radius dynauth client/server mibs structure stefaan.de_cnodder
- RE: radius dynauth client/server mibs structure Wijnen, Bert (Bert)
- RE: radius dynauth client/server mibs structure Nagi Reddy Jonnala (njonnala)
- RE: radius dynauth client/server mibs structure Nelson, David
- Re: radius dynauth client/server mibs structure Juergen Schoenwaelder
- RE: radius dynauth client/server mibs structure Romascanu, Dan (Dan)
- RE: radius dynauth client/server mibs structure Nelson, David
- RE: radius dynauth client/server mibs structure Wijnen, Bert (Bert)
- RE: radius dynauth client/server mibs structure Nelson, David
- RE: radius dynauth client/server mibs structure Wijnen, Bert (Bert)