radius dynauth client/server mibs structure
Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de> Wed, 08 February 2006 18:32 UTC
Envelope-to: radiusext-data@psg.com
Delivery-date: Wed, 08 Feb 2006 18:33:01 +0000
Date: Wed, 08 Feb 2006 19:32:31 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: radiusext@ops.ietf.org
Cc: Bert Wijnen <bwijnen@lucent.com>
Subject: radius dynauth client/server mibs structure
Message-ID: <20060208183231.GA8312@boskop.local>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: radiusext@ops.ietf.org, Bert Wijnen <bwijnen@lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.10i
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/>
- 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)