Re: looking for advise on RFC-2618 and 2620

[[e-mail]]

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 [e-mail] 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 [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>