[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: AD review: radius dynauth client/server mib documents
Inline
> -----Original Message-----
> From: Nelson, David [mailto:dnelson@enterasys.com]
> Sent: Friday, March 03, 2006 16:40
> To: Wijnen, Bert (Bert); radiusext@ops.ietf.org
> Subject: 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 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?
>
Yes, and that is why I had a very simple solution proposed later in
my review message. By adding that sentence, we make it clear that
we have thought about this and that such is indeed the case (assuming
that I got it right). By not saying anything about it, it could
be an unintended omission.
> > 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.
>
I think that answer is suffient for me.
Bert
--
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/>