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

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




Hi,

see below...

Wijnen, Bert (Bert) wrote:

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.


Ok, I will add a sentence the overview section to mention this. I believe this is better than in the MIB itself to avoid repeating the same for each object again.

Also the reference to the IANA copy-right web page will be removed.

thanks,
Stefaan




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

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