RE: looking for advise on RFC-2618 and 2620

["Carl Kalbfleisch" <carlk@netrake.com>]

I think the model is the interface MIB which provides discontinuity per interface.

Carl

> -----Original Message-----
> From: Barney Wolff [mailto:barney@databus.com]
> Sent: Wednesday, April 05, 2006 3:05 PM
> To: Romascanu, Dan (Dan)
> Cc: Nelson, David; stefaan.de_cnodder@alcatel.be; Carl Kalbfleisch;
> radiusext@ops.ietf.org
> Subject: Re: looking for advise on RFC-2618 and 2620
> 
> 
> On Wed, Apr 05, 2006 at 08:48:09PM +0300, Romascanu, Dan (Dan) wrote:
> > > 
> > > RADIUS can hardly be the only potentially distributed 
> > > application with this problem.  Perhaps mib-doctors can be 
> > > asked how others have solved it, or determined that such 
> > > internal issues must be kept hidden.
> > 
> > Hiding is certainly not good. Counter discontinuity objects 
> should be
> > defined when discontinuities happen at other time than
> > re-initialization, as per RFC 2578, Sections 7.1.6 and 
> 7.1.10 and RFC
> > 4181 Section 4.6.1.2. The granularity of the discontinuity objects
> > (global, per table, per row) is a function of whether 
> discontinuities
> > happen globally, or per interface, etc. 
> 
> Not to be tedious, but I was hardly suggesting that entities lie about
> discontinuities.  Rather, perhaps by using a buddy system or a central
> collection point, avoid them.  The issue is the extent to 
> which outside
> entities need to be aware of the distributed nature of some managed
> entity, or whether the entity should take pains to present a unitary
> appearance to the world.  There seems to be little stylistic guidance
> on this point, which becomes ever more relevant.  Your last sentence
> gives fine guidance for a vendor MIB on a particular design, but not,
> I submit, for a standard.
> 
> Barney Wolff
> 

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