The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <305D2EAC01C45448A7F3ECC487666F6C076569D7@md6370exch004u.nse.lucent.
com>, "Natale, Robert C (Bob)" writes:
> Hi Tom,
> 
> I appreciate your extensive implementation
> experience and your willingness to share
> your analysis with the group.  However, I
> strongly support Adrian's position on the
> issue of read-write objects in this (and
> most other) MIB.
> 
> The question "Is anyone really using it
> for provisioning anyway?" appears to be
> of the chicken/egg quandary type.  Well,
> now we have a "chicken" (so to speak!)
> in SNMPv3...let's have it give birth to
> lots of useful agents and applications.
> 
> The concept of producing a separate
> "Provisioning MIB" has its own merits
> when one means by that a higher-order
> MIB that would focus more on logical
> or service kinds of entities rather
> than specific transport level atomic
> objects.  However, such an endeavor
> should not, IMHO, obviate the need
> for and value of Set-ability of
> appropriate objects in lower-order MIBs.
> 
> Cheers,
> 
> BobN


Bob, 

I've been on the provider side of this and quite a long time ago Bay
networks made every aspect of their provisioning available in the MIB
and we found that completely *unacceptable* for various technical
reasons, some of which go away with SNMPv3, others which may not.

Router configurations can be huge and changes need to be atomic.  The
old way to do this was to do sets, then gets to verify the sets.  This
was excruciatingly slow and was not atomic.  Bulk sets may go a long
way toward solving this.  Even so, MIB dumps are barely human
readable.  There needs to be ways to generate configurations but also
ways for operators to read and eaily understand the configuration and
change them if needed.  A read-write MIB is poorly suited for this.

At this point I'm on the provider side of things and I'm not hearing
anyone that is running a network saying they want to configure their
network with SNMP.  All our MIBs are read-only and no customer
considers that a problem.

Given that situation we don't care if the IETF is defining MIBs to be
read-write or read-only.  We are implementing them read-only, advising
customers of that and not a single customer is complaining about it.
If they complain, we'll change but they haven't.

Curtis