[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: AD review: radius dynauth client/server mib documents
W.r.t.
> -----Original Message-----
> From: stefaan.de_cnodder@alcatel.be
> [mailto:stefaan.de_cnodder@alcatel.be]
> Sent: Tuesday, March 07, 2006 21:13
> To: Wijnen, Bert (Bert)
> Cc: Nelson, David; radiusext@ops.ietf.org
> Subject: 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.
>
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 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/>