RE: looking for advise on RFC-2618 and 2620

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

By the way, I can agree with a disontinuity timer object per row/entry
if it is available at that granularity.

Bert

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org]On Behalf Of Carl Kalbfleisch
> Sent: Wednesday, April 05, 2006 22:06
> To: Barney Wolff; Romascanu, Dan (Dan)
> Cc: Nelson, David; stefaan.de_cnodder@alcatel.be; 
> radiusext@ops.ietf.org
> Subject: RE: looking for advise on RFC-2618 and 2620
> 
> 
> 
> 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/>
> 

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