[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AD review: radius dynauth client/server mib documents
1. In the MIB MODULE IDENTITY DESCRIPTION clause it says:
DESCRIPTION
"The MIB module for entities implementing the server
side of the Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS) protocol.
Copyright (C) The Internet Society (2005). Initial
version as published in RFC yyyy;
for full legal notices see the RFC itself. Supplementary
information may be available on
http://www.ietf.org/copyrights/ianamib.html.";
That last sentence is NOT applicable. There is nothing in this MIB
module that is mainatined by IANA, so their copy-right web page is
not relevant. Fix is to just remove last sentence.
2. The a whole serioes of Counter32 objects.
I wonder what the object is to indicate a counter-discontinuity?
Or can such only happen at system restart/reboot?
See RFC2578 that explains this in sect 7.1.6
RFC4181, sect 4.6.1.2 (1st bullet) also speaks to it.
3. I see
radiusDynAuthClientAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The type of IP address of the RADIUS Dynamic
Authorization Client referred to in this table entry."
::= { radiusDynAuthClientEntry 2 }
radiusDynAuthClientAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The IP address value of the RADIUS Dynamic
Authorization Client referred to in this table entry,
using the version neutral IP address format."
::= { radiusDynAuthClientEntry 3 }
So, the radiusDynAuthClientAddress needs to specify that the address is
formatted according to the value of radiusDynAuthClientAddressType.
Also, as far as I can tell, any addressType could be present here,
so formally, you would need to describe when a dns name has been
resolved (if it occurs).
Same for both MIB documents.
Point 1 I can do with an RFC-Editor note.
Point 2 I can also address with an RFC-Editor not if the intend (default)
is that a dsiscuntinuity can only occur at system re-initiatlization.
If so, I suggest to add an entry to the DESCRIPTION clause of the
table itself that states:
Discontinuities for all counter32 objects in this table can
only occur at system re-initialization.
So no specific discontinuity onjects have been defined.
Point 3 Mmm... I guess there will only be ipv4 or ipv6 addresses.
If so, I can live with it since this is a read-only MIB module
and the doc is Informational.
Bert
> -----Original Message-----
> From: Wijnen, Bert (Bert)
> Sent: Friday, March 03, 2006 15:36
> To: 'Nagi Reddy Jonnala (njonnala)'; j.schoenwaelder@iu-bremen.de;
> radiusext@ops.ietf.org
> Subject: 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/>