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

Re: looking for advise on RFC-2618 and 2620


Hi Carl,



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.
I believe the discontinuity timer at MIB level is still needed for some scalars, and to have them in the table itself for each entry seems to be like a good idea based on your explanation.
Dave, the current version 05 was intended for IESG review. Should we wait for the IESG review to be finished or submit a version 06 as soon as possible? 

regards,
Stefaan
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/>


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