[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: radius dynauth client/server mibs structure
Are there implementations already?
If not, I would also recommend to make the change suggested by Juergen.
If yes, even then the suggested change is still simple now.
The disadvantage of not doing so is in the future when adding scalars
and thing not having grouped as nicely and so more complexity.
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.
Bert
> -----Original Message-----
> From: Nagi Reddy Jonnala (njonnala) [mailto:njonnala@cisco.com]
> Sent: Tuesday, February 14, 2006 11:24
> To: j.schoenwaelder@iu-bremen.de; radiusext@ops.ietf.org
> Cc: Bert Wijnen
> Subject: 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/>