[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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