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

["Wijnen, Bert (Bert)" <[e-mail]>]

W.r.t.

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Tuesday, March 07, 2006 21:13
> To: Wijnen, Bert (Bert)
> Cc: Nelson, David; [e-mail]
> Subject: Re: AD review: radius dynauth client/server mib documents
> 
> 
> 
> 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.
> 
Well, I strongly recommend to put it in the MIB module itself.
Normally I ask it to be in the DESCRIPTION clause of every object.
SO if you do a revision anyway, then I prefer that.
If you find that too much work, I would settle for it to occur
once in the xxxTable or xxxEntry DESCRIPTION clause to explain that
all COunter32 objets in this table have that behaviour w.r.t.
discontinuities.

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

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