[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: AD review: radius dynauth client/server mib documents
Bert Wijnen writes...
> 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 18.104.22.168 (1st bullet) also speaks to it.
RFC2578 Section 7.1.6:
The Counter32 type represents a non-negative integer which
monotonically increases until it reaches a maximum value of 2^32-1
(4294967295 decimal), when it wraps around and starts increasing
again from zero.
Counters have no defined "initial" value, and thus, a single value of
a Counter has (in general) no information content. Discontinuities
in the monotonically increasing value normally occur at re-
initialization of the management system, and at other times as
specified in the description of an object-type using this ASN.1 type.
If such other times can occur, for example, the creation of an object
instance at times other than re-initialization, then a corresponding
object should be defined, with an appropriate SYNTAX clause, to
indicate the last discontinuity. Examples of appropriate SYNTAX
clause include: TimeStamp (a textual convention defined in ),
DateAndTime (another textual convention from ) or TimeTicks.
RFC4181 Section 22.214.171.124 (1st bullet):
- It is OK to use Counter32/64 for counters that may/will be reset
when the management subsystem is re-initialized or when other
unusual/irregular events occur (e.g., counters maintained on a line
card may be reset when the line card is reset). However, if it is
possible for such other unusual/irregular events to occur, the
DESCRIPTION clause MUST state that this is so and MUST describe
those other unusual/irregular events in sufficient detail that it
is possible for a management application to determine whether a
reset has occurred since the last time the counter was polled. The
RECOMMENDED way to do this is to provide a discontinuity indicator
as described in RFC 2578 Sections 7.1.6 and 7.1.10. For an example
of such a discontinuity indicator, see the
ifCounterDiscontinuityTime object in the IF-MIB [RFC2863].
So I take it that the normal wrapping from maximum value to zero is OK,
and reset upon system (re)initialization is OK, but any other
"discontinuity" needs special attention. Is that right?
> So, the radiusDynAuthClientAddress needs to specify that the address
> 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).
RADIUS normally deals with IP Addresses, as the RADIUS client needs to
be registered with the RADIUS Server by IP Address, so that the correct
shared secret can be used. It is possible to use DNS with RADIUS
clients and servers, if sufficient care is taken to always have an
accurate inverse name resolution available, but I believe this is not
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.