RE: looking for advise on RFC-2618 and 2620

["Carl Kalbfleisch" <carlk@netrake.com>]

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org]On Behalf Of Nelson, David
> Sent: Tuesday, March 28, 2006 12:19 PM
> To: radiusext@ops.ietf.org
> Subject: RE: looking for advise on RFC-2618 and 2620
> 
> 
> Carl Kalbfleisch writes...
> 
> > I realize that these MIBs are being updated,
> > so perhaps we can add a discontinuity timer in a future revision. 
> 
> This is already an open issue from Area Director review of the revised
> MIB drafts, so will be included in the next draft version.
> 

Several more comments on discontinuity:

1) http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-05.txt defines only one object.

   radiusDynAuthClientCounterDiscontinuity OBJECT-TYPE
          SYNTAX TimeTicks
          UNITS  "hundredths of a second"
          MAX-ACCESS read-only
          STATUS current
          DESCRIPTION
                "The time (in hundredths of a second) since the
                 DAC module was last re-initialized."
          ::= { radiusDynAuthClientScalars 3 }

I recommend adding this attribute to the RadiusDynAuthServerEntry instead. The issue is that (for example in our box) we have instances of authentication MIB tables spread accross multiple nodes. Therefore it is possible for a node to reboot and have discontinuities independent of the mib as a whole.

2) The update to RFC-2618 http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2618bis-02.txt does not have a discontinuity timer. Again, I suggest adding the value to the table. Also, it there some reason why the authors did not just deprecate the radiusAuthServerAddress and then add the IPv6 attributes to the existing table. IE, why deprecate the entire table.

3) same comments as 2 for the uptdate to RFC 2620 - http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2620bis-02.txt

I have not implemented the server side mibs or reviewed the updates to them. The same or similar comments might apply.

> > if so, I would suggest adding it per radius entry so that
> > each server can have its own value.
> 
> That seems like a reasonable suggestion.
> 

Any idea when the next revision of the updates for 2618 and 2620 would be published?


> > One other point to note. We have found that radius servers respond
> faster
> > than 100th of a second. I'd suggest an update to the MIB where the
> > response time is stored in micro-seconds. In addition, having the
> minimum,
> > maximum and average are also helpful. We are adding such 
> values to our
> > enterprise MIB, but would opt for standard attributes if 
> they existed.
> 
> The revised MIBs have already been through WG last call and are now in
> IESG review.  Does the WG wish to recall the documents from the
> publication requested state to consider adding this kind of 
> new feature?
> 
> 

Any one interested in this?

Carl

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