[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: looking for advise on RFC-2618 and 2620
I think the model is the interface MIB which provides discontinuity per interface.
> -----Original Message-----
> From: Barney Wolff [mailto:email@example.com]
> Sent: Wednesday, April 05, 2006 3:05 PM
> To: Romascanu, Dan (Dan)
> Cc: Nelson, David; firstname.lastname@example.org; Carl Kalbfleisch;
> 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 126.96.36.199. The granularity of the discontinuity objects
> > (global, per table, per row) is a function of whether
> > 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 email@example.com with
the word 'unsubscribe' in a single line as the message text body.