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

[[e-mail]]

Hi,

see below...

Wijnen, Bert (Bert) wrote:

> Inline
> 
> 
>>-----Original Message-----
>>From: Nelson, David [mailto:[e-mail]]
>>Sent: Friday, March 03, 2006 16:40
>>To: Wijnen, Bert (Bert); [e-mail]
>>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 [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/>