RE: AD review: radius dynauth client/server mib documents

["Nelson, David" <dnelson@enterasys.com>]

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 4.6.1.2 (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 [3]),
   DateAndTime (another textual convention from [3]) or TimeTicks.

RFC4181 Section 4.6.1.2 (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
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).

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
common practice.


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