Re: Real serious problem

Peter Polkinghorne <Peter.Polkinghorne@brunel.ac.uk> Mon, 03 February 1997 17:23 UTC

Received: from cnri by ietf.org id aa25391; 3 Feb 97 12:23 EST
Received: from portal.ex.tis.com by CNRI.Reston.VA.US id aa15705; 3 Feb 97 12:23 EST
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA18359 for snmpv2-outgoing; Mon, 3 Feb 1997 12:13:33 -0500 (EST)
Message-Id: <12392.199702031716@dione.brunel.ac.uk>
X-Mailer: exmh version 1.6.6 3/24/96
To: Quality Quorum <qqi@world.std.com>
cc: Peter Polkinghorne <Peter.Polkinghorne@brunel.ac.uk>, snmpv2@tis.com
Subject: Re: Real serious problem
In-reply-to: Your message of "Mon, 03 Feb 1997 11:38:58 EST." <199702031638.AA24193@world.std.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 03 Feb 1997 17:16:53 +0000
From: Peter Polkinghorne <Peter.Polkinghorne@brunel.ac.uk>
Sender: owner-snmpv2@ex.tis.com
Precedence: bulk

 
> As I had chance to say my opinon on the subject had evolved over time on
> this subject: initially I was thinking that because one can advise perferct
> framework to write perfect SNMP Agent there is no such problem at all,
> over time I noticed that ever inside perfect framework somebody has
> still to write MIBs/application code which is still (1)unjustfiably
> complex and (2)still is not absolutely realiable.
>
Well I would not be so pessimistic - I think it is possible - but then may be 
the lack of security has not encouraged much in the way of settable MIB 
variables anyway.  But it is true that settable MIB variables are harder than 
one would hope for.
 
> I have an example which is much closer to Earth: what if  there is more
> than one source of control which is usually the case (e.g. gated
> and SNMP agent).
>

Well any system with multiple control interfaces has problems - the approach I 
would use is that:
a) the agent should always report what is the case - ie tell the truth
b) one interface is the master
c) document in the MIB the possible unreliabilities
 
> 
> > > I see two practical ways to resolve the problem:
> > > 
> > >   a. Add one more error-status value say  'requestTooComplex'
> > >
> > To which you had better define the simplification process - which will open a 
> > whole can of worms about what it means to update rows etc to leave things in a 
> > consistent state etc etc.
> 
> 
> ????? Requirement of atomicity/two phase sets  is nnot going to be
> compromised by this, this erro should be generated on the phase one
> before any changes take place.
>

Sorry, I was not making myself clear - how should the manager respond to the 
error message - that is what simplifications to make - preferably should be a 
well defined process.

 
> I am just making humble atempt to make SNMP a more atttactvie (it seems
> that you share my view that it is not scaling up well enough).

Well I do have the view that SNMP is not the be all and end all of distributed 
systems - may be my heritage of ODP/ANSA involvement is showing!
 

-- 
-----------------------------------------------------------------------------
| Peter Polkinghorne, Computer Centre, Brunel University, Uxbridge, UB8 3PH,|
| Peter.Polkinghorne@brunel.ac.uk   +44 1895 274000 x2561       UK          |
-----------------------------------------------------------------------------