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

RE: radius dynauth client/server mibs structure

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